- Symulator MaSzyna -

Symulator EU07 (i nie tylko) => Na warsztacie => Wątek zaczęty przez: firleju w 08 Września 2016, 10:51:21

Tytuł: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 08 Września 2016, 10:51:21
Witam,

Mam nadzieję, że jeszcze w tym tygodniu dam w tym wątku specjalne exe do testów. Pierwszą zmianą jak będzie wprowadzona będzie wyprowadzenie obsługi rozkładów jazdy z Pascala do c++. Dlaczego? Był to najprostszy moduł do zrobienia. Nie miał interakcji z pozostałymi plikami Pascala więc można było na nim przetestować np. wykorzystany konwerter.
Jakie są wstępne wnioski: konwersja nie będzie łatwa i przyjemna. Jest dużo takich fajnych kruczków, które powodują, że każdą linijkę trzeba przejrzeć, szczególnie przy obsłudze pętli oraz funkcji z ObjectPascala / Delphi.

Biblioteka glew32 potrzebna do uruchomienia (wejdzie w skład paczki) http://eu07.pl/forum/index.php/topic,28159.msg437252.html#msg437252
Tytuł: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: queuedEU w 08 Września 2016, 12:00:03
Na teraz moge powiedziec tyle, ze przetlumaczenie fizyki (bez hamulcow) bedzie prostsze jak tlumaczeie queryparsercomp.
Queryparsercomp'a generalnie nie oplaca sie tlumaczyc a powinno sie zastapic CParserem (nie powino byc z tym wiekszych probleow).
Na koniec pozostanie zamiana typow lancuchowych AnsiString, mysle ze najlepiej na string z std:: bo jest latwy w laczeniu.
Jezeli o niczym nie zapomnialem to bylyby te 3 kwestie do ogarniecia - fizyka, parser i AnsiStringi. Jesli by sie dobrze zmotywowac to
moglby byc to ostatni rok MaSzyny na starym srodowisku pisanej w dwoch jezykach. Jescze ciekawostka na koniec...
Odkrylem ze program mozna kompilowac w C++ Builderze 6 - tam tez jest support pascala, ale aby skomilowac nalezy zakomentowac pewna dyrektywe w cparser.cpp. Skutki uboczne sa takie, ze powstaje cos  stylu wycieku pamieci i natsepuje zawieszenie podczas wczytywania.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Cesky Kretek w 08 Września 2016, 12:46:08
Jak skończycie przenosić całą MaSzynę na C++ do końca tego roku to zamówię Wam po kracie piwa z dostawą do domu (jakieś Tesco Ezakupy czy inny Auchan Direct).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 09 Września 2016, 09:02:51
Jak narazie jestem na etapie sprawdzania czemu mi się wywala na EAccesVolation. Wygląda jakby nie inicjował mi zmiennej i jest ona ciągle NULL (chociaż jest inicjowana przed użyciem). Jako, że mam czas 2 x 0,5 godziny dziennie to nie widzę specjalnie możliwości przetłumaczenia tego do końca roku. Do tego jestem bezalkoholowy więc zgrzewka piwa odpada w przedbiegach ;)

  Dodano: 09 Września 2016, 09:12:12
PS.
Największe problemy obecnie są z określeniem czy dana struktura powinna być typu struct czy class.
Trzeba dopisać też często wszystkie konstruktory.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Benek w 09 Września 2016, 11:50:14
W C++ struktura i klasa to to samo. Różnią się tylko domyślnym typem dostępu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 09 Września 2016, 14:49:54
Nie wiem czemu to rozdzielili w zasadzie. Nie inicjuje się prawdopodobnie gdyż nie ma konstruktora (nie występuje coś takiego w Pascalu)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Benek w 09 Września 2016, 15:16:49
C++ to potomek C, chodzi o kompatybilność wsteczną napisanych już programów.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 10 Września 2016, 13:49:13
W każdym bądź razie to nie problem konstruktora, gdyż znalazłem takowe, i poprawnie się inicjują. Tylko cała zainicjowana klasa nie jest przypisywana do wskaźnika. Ma to chyba związek z warningiem linkera, że mam w wielu plikach obj zdefiniowaną zmienną (wszystkich w których inkluduje nagłówek ze zmienną). Nie wiem o co biega, gdyż definicja wygląda jak wszystkiego innego a tam nie ma takiego problemu. Zresztą jak było to w pascalu to nagłówek też miał tą zmienną i nie było takiego problemu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: El Mecánico w 10 Września 2016, 21:48:05
Firlej, a w *.hpp w którym jest deklaracja tejże klasy, lub wskaźnika, masz extern przy definicji?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 11 Września 2016, 11:12:07
Owszem, w .hpp jest. Tylko, że jak rozumiem extern używa się wtedy kiedy masz zmienną w bindingu. A w ty przypadku już nie inkluduję .hpp w ogóle. Ale spróbuję skompilować z extern w tym miejscu, może pójdzie.

  Dodano: 11 Września 2016, 12:39:27
Doczytałem sobie. Konwerter źle to zrobił i trzeba było poprawiać. To przy okazji następnych konwersji będzie przydatna wiedza. Było trzeba w nagłówku dać extern i drugi raz definiować zmienną w pliku cpp. Teraz działa poprawnie. Dalej walczę gdyż co coś poprawię to mam jakieś kolejne babole.

  Dodano: 11 Września 2016, 13:44:38
Muszę poprawić wszystkie odwołania liczbowe w substring, gdyż okazuje się, że AnsiString ma liczone od 1 a std::string od 0. No i AnsiString.SubString odwołuje się do innego miejsca w stringu niż std::string::substr w tym momencie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: janek32 w 11 Września 2016, 13:54:47
Generalnie struktura powstała już w C i może zawierać dane i wskaźniki na dane/wskaźniki na funkcję, i tak jak napisał @Benek, cała jej zawartość jest publiczna. Klasa została wprowadzona w C++ i może zawierać funkcje (metody), posiada konstruktory i destruktor, domyślnie (bez użycia słów kluczowych public: albo protected:) jej zawartość jest prywatna.
Nie jestem pewny, jak struktura zachowuje się w C++ (nigdy np. funkcji w strukturze pisać nie próbowałem), ale raczej dobrze jest trzymać w kodzie takie rozróżnienie i struktur używać do tego, do czego historycznie służyły.

Klasa w C++ nie musi mieć zdefiniowanych konstruktorów, jeżeli nie ma, używane są domyślne. ZTCW zwykły konstruktor wtedy nic nie robi, kopiujący po kolei przepisuje zawartość wszystkich zmiennych. Własne konstruktory i destruktor przede wszystkim trzeba zdefiniować, jeżeli w klasie wykorzystuje się dynamicznie przydzielaną pamięć - ale czasami to może być też wygodne w innych sytuacjach, po prostu jak przy inicjalizacji obiektu trzeba coś zrobić.

Co do ostrzeżenia linkera - próbowałeś użyć dyrektyw IFNDEF?
#ifndef _NazwaPliku_H_
#define _NazwaPliku_H_

(kod)

#endif _NazwaPliku_H_
Wtedy jeżeli oznaczony w ten sposób plik jest przy linkowaniu dołączany kilka razy, kod z niego trafia do głównego tylko raz.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 11 Września 2016, 14:07:30
#ifndef jest od samego początku. To była zmienna poza jakąkolwiek klasą i w związku z tym, że była w pliku nagłówkowym tylko to każdy cpp ją sobie domyślnie inicjował sam. Rozwiązaniem była deklaracja w nagłówku (extern) oraz definicja w jednym cpp. Teraz już działa.
W tej chwili walczę z funkcją konwersji int na string. W c++11 jest to_string(), ale wcześniej nie było i musiałem sobie zdefiniować taką globalną. Ale żeby była globalna zwraca static std::string to i nie chce mi jej dodawać do innego stringa za pomocą operator+. Chyba będę musiał użyć append.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: queuedEU w 11 Września 2016, 18:55:08
zrob sobie oddzielny modul z fukcjami, zobacz jak ja mam w qutils.h/cpp, laczenie jest bezproblemowe

atos atoi atof

lub

std::string itoss( int x ) {
  int length = snprintf( NULL, 0, "%d", x );
  assert( length >= 0 );
  char* buf = new char[length + 1];
  snprintf( buf, length + 1, "%d", x );
  std::string str( buf );
  delete[] buf;
  return str;
}

lub

std::string itoss(int val)
{
  std::stringstream ss;
  ss << val;

 return ss.str()
}

std::string itoss(int val)
{
 string tmp; // brzydkie rozwiązanie
 itoa(val, (char*)tmp.c_str(), 10);
 string str = tmp.c_str();
 return str;
}

char* itochp(int n)
{
     int i = 0;
     char tmp[12];
     static char ret[12];
     if(n < 0) {
      *ret = '-';
      i++;
      n = -n;
     }
     do {
      *tmp = n % 10 + 48;
      n -= n % 10;
      if(n > 9) *tmp++;
     }
     while(n /= 10);
     while(ret[i++] = *tmp--);
     return ret;
}
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 12 Września 2016, 08:22:29
Robię sprintf() ale coś nie bangla. Sprawdzę jak działa z twoją wersją.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: queuedEU w 12 Września 2016, 10:46:41
Jeszcze przyklad konwersji z float/double z obsluga wyjatku

inline std::string dtoss(double val)
{
  std::ostringstream o;
  if (!(o << val))
    throw BadConversion("stringify(double)");
  return o.str();
}
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 12 Września 2016, 16:09:03
Nie chcę używać strigstream narazie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: queuedEU w 12 Września 2016, 16:34:36
Jakies przeciwwskazania weszysz?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 12 Września 2016, 19:37:49
Patrzę w qutils i nie widzę tych funkcji. Chyba mam jakąś starą wersję repo, albo co. Skopiowałem twoją funkcję, ale jest taki problem, że:
int length = snprintf( NULL, 0, "%d", x );ta linijka zwraca mi -1 co teoretycznie oznacza problem ze zrzuceniem. Nie mam pojęcia jaki może mieć problem jeśli int przychodzi mu o wartości 18.
Nie chcę linkować całej biblioteki, żeby zrobić z niej jedną funkcję, którą docelowo i tak zamienię na std:to_string()
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: queuedEU w 12 Września 2016, 19:56:51
Moze zamiana %d na %i rozwiarze problem...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 12 Września 2016, 22:02:06
Nie rozwiązało. Zrobiłem na streamie i bangla. Borland sucks...

  Dodano: 12 Września 2016, 22:13:04
Dobra, w załączniku testowe exe. Bazuje na 478 plus parę commitów, więc nie ma tutaj wszystkich ostatnich poprawek. Sprawdzamy czy rozkład poprawnie się wczytuje oraz ogólnie wszystko działa jak poprzednio.

  Dodano: 13 Września 2016, 07:55:28
Rano narzuciłem zmiany z gałęzi głównej na moją gałąź. Delikatne poprawki na zmiany wprowadzone przez Stele i teraz możemy lecieć dalej z konwersją. Jak się będą objawiać jakieś błędy w rozkładach to poprawki będą na bieżąco.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 21 Września 2016, 07:27:53
Czuje się jak Ra. Wszyscy biorą, nikt nie napisze, że dobrze... Ehhh...
Dobra, koniec narzekania. Z najnowszych wiadomości z frontu to jestem gdzieś w połowie konwersji pliku OerlikonEst. Jako, że wygląda na dość spokojną końcówkę września jeśli chodzi o czas wolny (znaczy brak dodatkowych projektów) jest pewna szansa na zakończenie tego do końca tego miesiąca. Wbrew temu co pisze Q konwersja nie jest jakaś super prosta, gdyż konwerter nie zamienia automatycznie niektórych słów kluczowych object pascala na ich odpowiedniki w c++. W każdym razie powoli posuwam się do przodu zdobywając z każdą linijką nowe pole do wykazania się moją niewiedzą ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: queuedEU w 21 Września 2016, 20:05:39
Skoro czujesz sie jak @Ra to  w takim razie juz Cie nie lubie ;D, ale wracajac do tematu przepisywania hamulcow... Moje pytanie jest nastepujace - czy czujesz sie na silach przetlumaczyc te wszystkie moduly? Konkretnie chodzi mi o to ze tam jest pokomplikowane to wszystko poprzez te okropne dziedziczenie klas. Ja poleglem przepisujac to recznie kontrolujac i wiedzac co robie, Ty zas do tlumaczenia uzywasz jakiegos konwertera, a to nie wplywa pozytywnie na zapoznanie sie z
tym co sie przepisuje - tak mi sie przynajmniej wydaje :). Mysle ze powinienes ogarnac prostsze sprawy np. takie jak zamiana typow lancuchowych
na std::string czy, zamiana parserow na CParser, bo po przetlumaczeniu SPKSa, moze okazac sie, ze MaSZynum zawiesza sie na wczytywaniu scenerii :D.
Mozesz mi nie wierzyc Grzesiu, ale hamulce najlepiej zostawic na sam koniec - bo najtrudniejsze :).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Balaclava w 21 Września 2016, 20:22:18
Zassałem exe na dysk i próby odpalenia misji na Quarku, l61_pospieszny (tej od @Ra) i l053-sluzba2-night zakończyły swe wczytywanie na takiej oto linijce:
New timetable for [nazwa_loka]: rozkladCzysta paczka + patch 16.08.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 21 Września 2016, 20:57:51
Mi się ładuje. Przetestowałem na l61_regio od Ra.
Wyjazd z Osobowej zaświeciło na zielono i usunęło z tabelki. W pierwszym wersie w kolejnej stacji jednak nadal wyświetla "Częstochowa Osobowa" i po zatrzymaniu się na Stradomiu nie reaguje na W4.
Z moich ostatnich zmian, to nie odtwarza dźwięku drzwi.
Na td przy pustym rozkładzie zawiecha na ładowaniu rozkładu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 22 Września 2016, 08:42:35
@Krzysiek: Zawiecha na ładowaniu rozkładu to jest brak wyjścia z pętli. Na pewno masz ostatnie exe? Bo poprawiałem na pewno ten błąd. Podaj mi który rozkład ładowałeś w misji l053 to spróbuję na td go załadować i zobaczę co się stanie.
@Stele: Brak skasowania odjazdu to raczej nie jest wina konwersji. Cała obsługa pozostała tak jak poprzednio. Na normalnym exe też się tak zachowuje?
@Q: Nie ma większego znaczenia czy zacznę od najtrudniejszego, czy najłatwiejszego. Teoretycznie zacząłem od najłatwiejszego, a okazało się, że cały moduł jest zakręcony jak jelita. Wiem, że tu jest fajne dziedziczenie, ale da się to opanować. Podpieram się tym co generuje Borland do bindingów.

  Dodano: 26 Września 2016, 08:51:15
Kolejne wieści z frontu:
Całość modułu jest przetłumaczona. Niestety nie kompiluje się, gdyż w Pascalu w jednej funkcji użyty jest parametr domyślny na zmiennej i okazuje się, że przez binding to nie działa. Więc albo dopisze sobie funkcje w Pascalu, albo od razu przetłumaczę komplementarny plik, bo robienie funkcji inline po to żeby ją zaraz skasować chyba nie ma sensu. W takim układzie do tłumaczenia idzie hamulce.pas.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mac310 w 27 Września 2016, 21:28:49
Nie mam teraz na nic czasu więc ani nie mogę pojeździć na działającym exe, ani potestować niczego nowego. Chwila w hotelu i mała próba z TD i 478c1 i zawiesza się ładowanie na komunikacie "New timetable for ep07-424: rozklad" więc nie potestuję niczego więcej :(
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 27 Września 2016, 22:17:04
Czyli ma problem z pustymi rozkladami. Testowałem tylko na istniejących. Ehh...

  Dodano: 29 Września 2016, 13:46:06
Z placu boju: jestem w połowie pliku hamulce.pas. Rozkładami się zajmę jak to skończę, gdyż jeśli dobrze pamiętam, to będzie trzeba napisać ładowanie od nowa.

  Dodano: 30 Września 2016, 14:43:58
Stan na dzisiaj: wstępnie poprawiony hamulce.cpp. Szacun dla króliczka bo myślałem, że nie skończę tego pliku. Teraz jeszcze pozostało posprawdzać co źle zostało skonwertowane i dorzucić konstruktory z pliku generowanego przez Borlanda.

  Dodano: 02 Października 2016, 10:58:26
Stana na 02.10: pliki kompilują się poprawnie, jednak linker ma problem z odwołaniami przy _mover. Będę musiał posprawdzać do czego się odnoszą poszczególne pozycje. natknąłem się też na parę funkcji, które bardzo chętnie bym użył, tylko pojawiły się od C++11 i narazie napisałem protezy. Stąd prawdopodobnie hamulce mogą nie do końca zachować się tak jak powinny do czasu poprawnej implementacji (no chyba, że to nie ma znaczenia, ale nie jestem w stanie tego rozpoznać). Chodzi o funkcję Round(i_bcp).

  Dodano: 03 Października 2016, 07:33:27
03.10: Zacząłem od tyłka strony okazuje się. Nie zbuduję projektu dopóki całe mover nie pójdzie do konwersji. W związku z tym dzisiaj rankiem do tłumaczenia poszło friction.pas i po południu zaczynam _mover.pas. Prośba do jubaja o konsultacje w sprawie macierzy, które zakres miały ujemne .. dodatnie: czy wystarczy że w implementacji będę do zmiennej otrzymanej dodawał tak, że przy zgłoszeniu najbardziej ujemnej wartości zwróci mi 0?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 20 Października 2016, 14:46:01
Witam po dłuższej przerwie.
Stan na 20.10: _mover przetłumaczony. W tym miejscu podziękowania do Q za jego wielki wkład. Obecnie dalej exe się nie kompiluje, gdyż zmieniam wszystkie AnsiString na std::string, co jeszcze chwilę potrwa. Zmieniam też wszystkie funkcje z bibliotek Borlanda na standard C++98 (jak coś jest w tylko bibliotece standardowej C++11 to dopisuję na szybko do mctools do czasu przejścia na nowszy kompilator). Jeszcze nie wiem czy rozwiązałem problem z tablicami BPT, ale to pewnie okaże się jak w końcu uda mi się wszystko skompilować. Nie poprawiłem jeszcze błędu zawieszania wczytywania pustych rozkładów, ale to jest kwestia przywrócenia jednej funkcji do stanu korzystającego z funkcji w mctools i powinno być już dobrze. Dalszy postęp prac jest uzależniony od dostępności czasu (a może go być mało, ale wcale nie musi). Aktualny kod dostępny na repo w branchu "mover in c++".
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Cesky Kretek w 21 Października 2016, 11:06:48
Czy dostęp do źródeł przepisanych na C++ będzie (bądź jest) ogólnodostępny jak w przypadku starych źródeł?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 21 Października 2016, 11:12:35
Jest dostępny ogólnie: github.com/firleju/maszyna

  Dodano: 21 Października 2016, 11:13:30
Zaznaczam, że w obecnej chwili projektu nie da się skompilować ze względu na nieskończone zmiany.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Cesky Kretek w 21 Października 2016, 15:11:35
Spoko, zastanawiam się czy kod C++ nie lepiej żeby był na chwilę obecną dostępny tylko dla developerów pracujących nad nimi.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 21 Października 2016, 19:12:32
To nie ma znaczenia dla mnie. Oszem, mogę przestać wrzucać następne wersje i zrobić sobie jakieś chwilowe repo na bitbucket, ale nie wiem czy jest sens. Oficjalne repo jest gdzie indziej, a prywatne repa na githubie są płatne niestety.

  Dodano: 25 Października 2016, 09:16:48
Z placu boju: powoli zaczyna kompilować się większość plików. W tej chwili drążę DynamicObject. Nie uda mi się na pewno przy tym podejściu wyrzucić wszystkich zależności od STL Borlanda. Najpierw zbudowanie projektu i poprawa wszystkich błędów, które na pewno się objawią. Pamiętam też o błędach w rozkładzie jazdy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 25 Października 2016, 17:51:42
Nie wiem co miałoby na celu zamykanie źródła. Repo na Gicie i tak ma prawa zapisu tylko dla autora, reszta z tego co wiem może co najwyżej wysłać pull request albo rozwijać swojego forka. W sumie im więcej osób zobaczy kod tym lepiej (bo może przykładowo błąd wyłapać), ale znając życie mało kto zagląda. Z tego co wiem nawet niektóre komercyjne projekty są Open Source, właśnie ze względu na większą szansę wyłapania błędów. Co do forkowania - IMHO strata czasu. No chyba, że się potem połączy to jakoś.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 25 Października 2016, 22:06:46
W tej chwili flow wygląda tak, że Stele ma forka, wysyła do mnie PullRequest, ja go akceptuję. Po jakimś czasie robię PullRequest to głównego repo. Nikt inny nic nie wysyła, więc się nie martwię specjalnie.

  Dodano: 26 Października 2016, 08:06:19
Przeszedłem z DynamicObject na TMoverParamters. Ubawiłem się jak zacząłem poprawiać funkcję w związku z przejściem na std::string i stwierdziłem, że Q napisał niektóre funkcje raz jeszcze.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 26 Października 2016, 22:11:19
... zastanawiam się czy kod C++ nie lepiej żeby był na chwilę obecną dostępny tylko dla developerów pracujących nad nimi.
Skad taki pomysl? Prosze nie odpowiadac, pytanie jest czysto retoryczne. Schowanie zrodel juz raz sklocilo uzytkownikow forum, to chyba jest jakas nauczka. Jestem za tym, aby wszelkie propozycje solidnie uzasadniac.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Cesky Kretek w 27 Października 2016, 00:28:27
Wiem, sam przecież byłem i dalej jestem za otwartymi źródłami ale w formie końcowej (działającej). Na chwilę obecną skoro są przepisywane pojedyncze funkcje tak naprawdę można odwalić czarną robotę a ktoś skorzysta z gotowych rozwiązań - co innego gdy mamy już działającą np. wersję 1.0. Jeżeli uważacie że nie ma to sensu to nie ma sprawy, to była tylko luźna propozycja.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 27 Października 2016, 09:03:35
Moje repo na githubie jest robocze. Oficjalne, działające, wersje są na innym koncie (możemy go nazwać oficjalnym). Nie widzę sensu chować tych prac bo i tak nikt z nich nie skorzysta, bo się nie da tego skompilować obecnie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: El Mecánico w 27 Października 2016, 17:37:38
@Firlej, a czy na obecnym etapie dało by się już "odpiąć" sterowanie pojazdem od klawiatury?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 27 Października 2016, 19:34:34
Szczerze powiedziawszy to nie wiem. Sterowanie jest bodajże zaszyte gdzieś w kodzie przy pomocy skanowania wejścia. Klawiaturę trzeba będzie zostawić i to jest pytanie jak to zrobić wtedy inaczej, a raczej jak wprowadzić alternatywę.

  Dodano: 28 Października 2016, 08:18:53
Prace idą do przodu. W tej chwili jestem na RealSound gdzie trzeba zmienić "tylko" char* na const char* ;) Tak zupełnie przy okazji wymuszam poprawne tworzenie tych obiektów poprzez stworzenie konstruktora. Wkurza mnie jak nie wiem stare podejście: najpierw tworzymy klasę a potem ręcznie dopisujemy zmienne więc są one publiczne tylko z tej okazji. Fajne miejsce żeby mieć wysypy jak czegoś zapomnisz dopisać.
Muszę niestety stwierdzić, że kod będzie można użyć jako całość albo w ogóle, gdyż jest za dużo zmian. Coś jak ze zmianami Q z zeszłego roku.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: adamst w 28 Października 2016, 10:17:12
Szczerze powiedziawszy to nie wiem. Sterowanie jest bodajże zaszyte gdzieś w kodzie przy pomocy skanowania wejścia. Klawiaturę trzeba będzie zostawić i to jest pytanie jak to zrobić wtedy inaczej, a raczej jak wprowadzić alternatywę.

Osobiście widziałbym mechanizm takiego rodzaju, że w trakcie skanowania wejścia naciśnięcie/zwolnienie klawisza generuje jakieś tam komunikaty w rodzaju "KeyXXXOn/KeyXXXOff", natomiast ich powiązanie z konkretnymi funkcjami pojazdu dokonywałoby się np z poziomu mmd.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 28 Października 2016, 18:14:01
To już prędzej trzeba zrobić klasę bazową, która ma pewne API na zbieranie poleceń ze świata zewnętrznego. Wtedy możemy pisać osobne klasy, które np. będą potomne i w zależności od tego jakie dane będą zbierać będą przetwarzać na ustalone kody poleceń. W tej chwili wielokrotne parsowanie stringów (bo tak przesyłane są polecenia między modułami) może nie jest krytycznym elementem do natychmiastowej optymalizacji, ale zdecydowanie nie jest eleganckim rozwiązaniem, które pozwala na różną rozbudowę funkcjonalności (nie ma np. wspólnej bazy komend i trzeba ręcznie wpisywać te samy nazwy wielokrotnie).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: El Mecánico w 28 Października 2016, 19:59:30
Dokładnie to potrzebujemy czegoś, co poprzez klawiaturę będzie oddziaływało TYLKO na elementy które mechanik może obsługiwać w kabinie. Dalej, między kabinę i fizykę, wpinamy sterowanie w LD. Interfejsy najlepiej zrobić na vector<bool>, bo bit na styk jest wystarczający.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 30 Października 2016, 21:39:53
Tak myślę, że powinien być zestaw modułów zbierających wejścia z rożnych interfejsów i współdziałający z jednym modułem który już bezpośrednio pracuje z elementami exe. Wtedy można podpinać różne urządzenia jednocześnie. Komunikacja za pomocą zdefiniowanego API. Czy moduł współpracujący wewnętrzny będzie zmieniał zmienne dla LD czy robił coś innego to już sprawa wtórna.

  Dodano: 31 Października 2016, 09:19:44
Dzisiaj rano udało się zbudować projekt. Niestety nie da się obecnie uruchomić gdyż wyrzuca błąd dostępu do pamięci ale debugger nie pokazuje w którym miejscu. Jest także 3k warningów co może mieć przyczynę. Może ktoś mi wytłumaczy czemu zmienna globalna inicjowana w nagłówku wg kompilatora jest generowana w każdym pliku cpp który includuje ten nagłówek pomimo ifndef? Być może wyrzuca właśnie tutaj.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 31 Października 2016, 12:39:16
Może ktoś mi wytłumaczy czemu zmienna globalna inicjowana w nagłówku wg kompilatora jest generowana w każdym pliku cpp który includuje ten nagłówek pomimo ifndef? Być może wyrzuca właśnie tutaj.
ifndef zabezpiecza tylko przed uzyciem tego samego naglowka po kilka razy przy kompilowaniu jednego .cpp, ale nie powstrzymuje kompilatora przed wlaczeniem tego naglowka i wygenerowaniem kopii zmiennej dla kazdego .cpp z osobna. A potem linker wariuje bo nagle ma cala kope kandydatow na zmienna globalna, zamiast jednej sztuki.

Od takich rzeczy jest extern tzn. w plikach .h robisz np.

extern std::string foo;

a potem w jednym tylko .cpp ma miejsce wygenerowanie zmiennej czyli

std::string foo = "bar";

i linker to wszystko sobie wtedy posklada.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 31 Października 2016, 14:16:40
No tak właśnie myślałem, że będę musiał przez extern pójść. Jak będę wracał do domciu to skompiluję raz jeszcze i zobaczymy czy zabangla. Ofkoz są błędy, gdyż nie udało się poprawnie załadować charakterystyk, ale mimo wszystko jednak nie powinien się na tym wysypać.

  Dodano: 01 Listopada 2016, 06:42:11
Z placu boju: Exe się buduje. Nie ma warningów, aczkolwiek kompilator stał się bardo niestabilny i co jakiś czas muszę kasować wszystkie pliki .obj. Wyrzuca błąd, który jak to producent określa "nie powinien występować w praktyce". W tej chwili poprawiam nowe funkcje ładowania plików charakterystyk napisane przez Q.

  Dodano: 02 Listopada 2016, 08:03:50
Mam ochotę zabić Borlanda. Otóż okazuje się, że wszystkie zmienne typu bool, jeśli ich nie zainicjujesz otwarcie, domyślnie ustawione są na true. No i całość trzeba wziąć i dopisać otwarcie. Aaaaa....
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: El Mecánico w 02 Listopada 2016, 19:46:37
Heh, kompilatory GNU domyślnie nie ustawiają żadnych wartości dla typów podstawowych, tak więc są tam wartości losowe, jakie akurat zostały w RAM w chwili rezerwowania adresu...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 02 Listopada 2016, 20:21:28
Inicjalizacja zmiennych w sumie powinna byc w kodzie od poczatku, wlasnie dlatego ze w standardzie nie ma gwarantowanych wartosci domyslnych. Pewnie warto by przy przenosinach sprawdzic wszystko pod tym katem, bo wiecej takich kwiatkow moze wyskoczyc...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 02 Listopada 2016, 21:37:58
Pierwsze przykazanie programisty maszyny: Będę używał konstruktora zgodnie z jego przeznaczeniem, a nie funkcji Init, którą muszę ręcznie uruchomić później.

  Dodano: 04 Listopada 2016, 21:05:36
Witam. Stana na 04.11: wyrzucam funkcję Init z wszystkich klas hamulców (jak się bawić to na całego) i dostosowuję do tego inicjację DynamicObject. Idzie nieźle.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 05 Listopada 2016, 11:59:06
Możesz dać namiary na repo, gdzie puszczasz commity?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 05 Listopada 2016, 20:11:12
github.com/firleju/maszyna - branch mover_in_c++. Nie jest kompilowalne w czymś innym niż Borland jak na razie, gdyż jeszcze korzysta w niektórych miejscach z STL Borlanda oraz w paru miejscach z parsera delphi.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 05 Listopada 2016, 21:30:56
Dzięki. Zapewne planujesz większe porządki w kodzie dopiero po przeniesieniu?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 06 Listopada 2016, 09:55:33
Najpierw chcę zejść z Borlanda. Potem dobrze będzie zejść z bezpośrednich odwołań do konkretnych windowsowych API (np uchwyt do okna, dźwięki). Tutaj są najróżniejsze opcje i niczego nie przesądzam. Kiedyś myślałem nad użyciem Qt a Shax do dźwięku proponował OpenAL, ale to może być cokolwiek innego co pozwoli skompilować exe na inne systemy niż windows i ewentualnie obejść problemy jakie mamy w tej chwili (np. obsługa różnych formatów plików dźwiękowych).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 06 Listopada 2016, 12:20:42
Próbowałem zrobić większą swobodę wava przy pomocy konkretnych windowsowych api ostatnio, ale działało kompletnie inaczej, niż w dokumentacji. :P
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 08 Listopada 2016, 07:40:43
Przeszedłem inicjację hamulców. Teraz sypie się na animacji pantografów. Kaj czort? Jakim prawem, nic tam nie tykałem. Ehhh...

  Dodano: 08 Listopada 2016, 18:15:24
Znalazłem przyczynę wywałki. Źle użyłem funkcji sprawdzającej długość wczytanego pliku i w związku z tym nie parsował w ogóle plików mmd. Exe nie sprawdza czy ten plik został poprawnie sparsowany, co niczym samym w sobie nie szkodzi. Tylko, że w konstruktorze DynamicObject domyślnym ustawieniem liczby pooszczególnych obiektów definiowanych po słowie "animations" nie było 0 tylko maksimum. W związku z czym pomimo nie parsowania tego pliku exe wierzyło, że coś tam jest i próbowało się odwołać do tablicy, która była NULL.

  Dodano: 08 Listopada 2016, 19:38:39
Pierwsze koty za płoty. Exe wstało poprawnie i nawet wyświetliło wszystko poprawnie. Szkoda tylko, że nie działa podnoszenie pantografów...

  Dodano: 08 Listopada 2016, 21:34:15
Wygląda, że działa. Szkoda, że dzieci mi popsuły klawiaturę i sobie nie pojeżdżę. Teraz jeszcze poprawka na pusty rozkład i do testów.

  Dodano: 09 Listopada 2016, 19:49:10
Powinno już ładować pusty rozkład. Testowe exe w załączniku. Może mnie ktoś oświecić czemu uruchomienie w debugerze Borlanda powoduje, że nie wyświetla obrazu i jakby się zawiesza w przesuwaniu składu po torze, a przy normalnym uruchomieniu wszystko jest ok? Dawniej coś takiego mi się działo od czasu do czasu, ale najczęściej uruchomienie ponowne pomagało. Teraz nic nie pomaga i nie jestem w stanie uruchomić żadnej trasy w trybie AI, żeby złapać ewentualne wysypy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 09 Listopada 2016, 23:56:20
Nie wiem czy to Twoja klawiatura, ale ja widzę, że hamulce nie działają w ogóle. Stan początkowy jest dziwny: hasler tyka i pokazuje między 15-20km/h. Wskazówka się buja. Nie startuję we właściwej kabinie. Da się włączyć rozrząd, podnieść patyki, a nawet włączyć przetwornicę i sprężarkę. Ale po nabiciu ciśnienia jakiekolwiek manipulacje kranem hamulca nic nie dają. Wcisnąłem 2x numlock i kran zaczął działać, tzn można nim kręcić, ale bez żadnego efektu na PG. Spróbowałem użyć odluźniacza, ale spuścił mi ciśnienie ze zbiornika głównego, a nie cylindrów hamulcowych. Oczywiście po spuszczeniu powietrza z ZG patyki opadają.

Coś jest z wyświetlaniem grafiki - u mnie Alt+Tab powoduje wyczyszczenie ekranu ładowania który staje się czarny, widać jeden napis na nim tylko. Symulacja się uruchamia, ale wiesza przykładowo po zmianie kabiny.

I jeszcze jedno - niektóre błędy w plikach scenerii / dynamic powodują wyświetlenie dialogu systemowego wymagającego przejścia do niego przez Alt+Tab i kliknięcia OK. Jakbyś mógł to usunąć i zastąpić po prostu zapisaniem linijki w logu byłoby super.

Testowałem na TD i Zwierzyniec Transport.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 10 Listopada 2016, 08:55:34
Czyli jednak muszę kupić sobie klawiaturę, żeby więcej potestować. Ostatnia jaką kupiłem była kiepska więc mi nie żal, że ją dzieci uszkodziły. Te okna błędów były już wcześniej, jeśli dobrze widziałem w kodzie, ale bez problemów można to usunąć. Czyli walczymy dalej.

  Dodano: 10 Listopada 2016, 08:58:30
P.S. Dzisiaj już debugger działa. It's a kind of magic, magiiiiiccccc.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 10 Listopada 2016, 11:49:25
Ja potwierdzę opisane błędy przez @HTD. Dodam jeszcze, że w trybie testowym nie udało mi się odluźnić lokomotywy. W trybie normalnym pojechałem, wygląda na to jakby nie było fizyki. Nie ma też pozycji nastawnika, działa jakbym sterował kolejką elektryczną.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 10 Listopada 2016, 13:44:39
Hamulce to wiem gdzie prawdopodobnie jest błąd. Tam były tabele które w Pascalu mają ujemne indeksy i jak widać nie udało mi się tego porządnie odtworzyć w c++.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 10 Listopada 2016, 18:59:18
Taka drobna sugestia jeszcze, jakby to było trywialne (w innym wypadku szkoda czasu): jak się symek ładuje, wyświetla na ekranie startowym napisy co się ładuje, ale wygląda na to, że ten wątek jest odcięty podczas ładowania, dlatego ten ekran się nie odświeża. Przy przełączeniu via Alt+Tab czasem coś się dzieje z tym ekranem, napisy się aktualizują. A czasem nie. W wersji skonwertowanej widać, że ekran wtedy próbuje się odświeżyć, ale nawet tła nie rysuje. Zgaduję, że brakuje przepuszczania komunikatów przez to okno przed startem symulatora. Z innych drobiazgów - byłoby super czadowo, gdyby plik log.txt był otwierany w trybie współdzielenia odczytu. W tym momencie inna aplikacja mogłaby go czytać podczas pracy symulatora. To samo odnośnie plików w physicslog, chociaż akurat tych nie sprawdzałem. Wydaje mi się, że wystarczy tylko ustawić 1 flagę przy otwieraniu. To blokowanie ekranu startowego i logów istnieje oczywiście w obecnej wersji, ale jeśli przy przepisywaniu można to szybko zmienić, to już nowa wersja mogłaby zyskać ciekawe właściwości. Ogólnie to jest tak, że plik log.txt mogę odczytać wyłącznie po zamknięciu symka, wcześniej system widzi go jako plik o długości 0.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 10 Listopada 2016, 19:19:22
Cytuj
Ogólnie to jest tak, że plik log.txt mogę odczytać wyłącznie po zamknięciu symka, wcześniej system widzi go jako plik o długości 0.
To ciekawe co piszesz, jakiś czas temu należało zamknąć i powtórnie otworzyć czytany tekst, aby zaktualizować dopisany przez aplikację tekst. Nigdy nie miałem problemu z czytaniem pliku log.txt na bieżąco w trakcie symulacji.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 11 Listopada 2016, 09:55:55
Walczę z hamulcami narazie. Loga nie będę ruszał. Cały czas jest tak jak był - w zasadzie po każdym zdarzeniu następuje zapisanie od pliku.

  Dodano: 14 Listopada 2016, 08:48:13
Do d... Zafiksowałem się na jednym rozwiązaniu co mi utrudniło robotę. Sprawdziłem alternatywę i wyszło, że trafienie w std::map przy 12 pozycjach wynosi O(1,07) zamiast O(1) przy zwykłej tablicy. Natomiast przy 8 pozycjach (dla kranu FV4aM) wynosi O(0,9) ;) A użycie std::map rozwiązuje większość problemów i jest "kompatybilne" z ujemnymi indeksacjami tablic w Pascalu.

  Dodano: 14 Listopada 2016, 23:33:09
Coś jest ostro zwalone. Hamulec pomocniczy sam się zaciąga i za ChRL nie chce ustawić się w innej pozycji. Główny w ogóle nie reaguje. A Hasler pokazuje jakąś losową wartość około 18 i lekko drga. Czyli cały mover jest do solidnego przejrzenia. Najpierw to wszystko uruchomić, potem dopiero zabawa w optymalizację.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 15 Listopada 2016, 07:25:39
Do d... Zafiksowałem się na jednym rozwiązaniu co mi utrudniło robotę. Sprawdziłem alternatywę i wyszło, że trafienie w std::map przy 12 pozycjach wynosi O(1,07) zamiast O(1) przy zwykłej tablicy. Natomiast przy 8 pozycjach (dla kranu FV4aM) wynosi O(0,9) ;) A użycie std::map rozwiązuje większość problemów i jest "kompatybilne" z ujemnymi indeksacjami tablic w Pascalu.
std::map jest implementowana z uzyciem red-black tree, stad jest wolniejsza. Jesli potrzebujesz O(1) uzyj std::unordered_map (http://en.cppreference.com/w/cpp/container/unordered_map)  Interface jest o ile dobrze pamietam taki sam, wiec to tylko zmiana kontenera, a unordered_map jest oparta o hash, wiec z reguly da ci linearny czas dostepu.

(poza tym najpierw robi sie implementacje, a optymalizacje to ewentualnie i po testach ktore wykaza ze jest tu w ogole problem do usuniecia ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 16 Listopada 2016, 07:52:22
Panie, Panie. Kompiluje na Borlandzie 5.02 (rok. prod. 2000). Nie na VS2013. Żadnego unordered_map nie ma.

  Dodano: 16 Listopada 2016, 08:02:38
P.S.
W tej chwili nie ma żadnego profilera, na którym można sprawdzić jak się kod zachowuje. Mam nadzieję, że jak się uwolnimy od Borlanda to uda się takie narzędzie wprowadzić i zobaczymy co zajmuje nam dużo czasu, a co nie jest problemem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 16 Listopada 2016, 16:38:43
A to ja przepraszam :)  Myslalem, ze wszystkie zaleglosci z Borlanda juz sa wyprute.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 16 Listopada 2016, 21:42:13
Sprawdzam co się porobiło z moverem, że nie chce toto działać. Potem zostaje już "tylko" główny parser QueryParserComp. Jak on pójdzie to będzie już z górki.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 16 Listopada 2016, 22:08:11
A nie da sie zastapic Query na cParser, zamiast przepisywac Query? W sumie oba robia to samo, tyle ze jeden sie kompiluje poza Borlandem a drugi nie ;) Z tego co widze w kodzie to Query jest uzywany tylko do wyciagania tokenow jeden po drugim ze stringa, wiec nawet nic dopisywac nie trzeba, co najwyzej pozmieniac odwolania.

troche czytelniej by sie tez zrobilo. np. zamiast
(w geom.cpp)
        tf = Parser->GetNextSymbol().ToDouble();
        TempVerts[i].Point.x = tf;
        tf = Parser->GetNextSymbol().ToDouble();
        TempVerts[i].Point.y = tf;
        tf = Parser->GetNextSymbol().ToDouble();
        TempVerts[i].Point.z = tf;
        tf = Parser->GetNextSymbol().ToDouble();
        TempVerts[i].Normal.x = tf;
        tf = Parser->GetNextSymbol().ToDouble();
        TempVerts[i].Normal.y = tf;
        tf = Parser->GetNextSymbol().ToDouble();
        TempVerts[i].Normal.z = tf;

moglo by wejsc
Parser->getTokens( 6, false );
*Parser
>> TempVerts[i].Point.x
>> TempVerts[i].Point.y
>> TempVerts[i].Point.z
>> TempVerts[i].Normal.x
>> TempVerts[i].Normal.y
>> TempVerts[i].Normal.z;

itp. Latwiej wtedy wylapac literowki i inne pluskwy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 17 Listopada 2016, 08:22:19
Byłbym bardzo wdzięczny jeśli byś chciał się tym zająć. Ta zmiana powinna być możliwa do zrobienia niezależnie od moich prac nad konwersją. Ogólnie sam cParser jest określony jako mniej wydajny niż Query. Da się to zoptymalizować, gdyż w tej chwili robi alokację stringa z każdym pobraniem znaku. Jeśliby robić tą alokację na każdym słowie myślę, że byłoby zdecydowanie szybciej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 17 Listopada 2016, 16:59:36
Da się to zoptymalizować, gdyż w tej chwili robi alokację stringa z każdym pobraniem znaku. Jeśliby robić tą alokację na każdym słowie myślę, że byłoby zdecydowanie szybciej.
Hmm? Moze ja zle patrze, ale w zrodlach tego nie widze... alokacja jest robiona raz na slowo:

std::string cParser::readToken(bool ToLower, const char *Break)
{
    std::string token = "";

(...)

    char c;
    do
    {
        while (mStream->peek() != EOF && strchr(Break, c = mStream->get()) == NULL)
        {
            if (ToLower)
                c = tolower(c);
            token += c;
            if (trimComments(token)) // don't glue together words separated with comment
                break;
        }
    } while (token == "" && mStream->peek() != EOF); // double check to deal with trailing spaces
edit: jesli masz na mysli, ze bedzie miala miejsce re-alokacja przy token += c, to wiekszosci mozna uniknac przez dodanie
    std::string token = "";
    token.reserve(16); // should be enough in most cases
a jeszcze lepiej wrzucic token do naglowka jako member, i tylko kasowac zawartosc w readToken().

Ogolnie rzecz biorac akurat tutaj wydajnoscia bym sie specjalnie nie przejmowal -- parser jest uzywany glownie do wczytywania konfiguracji podczas ladowania itp, wiec waskim gardlem i tak bedzie przede wszystkim odczyt z dysku.

Co do zajecia sie, nie mam niestety Borlanda wiec raczej nie jestem w stanie -- poprawki musialbym robic "na sucho" bez mozliwosci sprawdzenia czegokolwiek. Ale z tego co widze, to prowizorycznie wystaczyloby dopisac do cParsera:
std::string GetNextSymbol() {

std::string token;
getToken( token );
return token;
}
I tak z 90% istniejacego kodu lyknie zwykla zamiane "TQueryParserComp" na "cParser" (nie bedzie to najbardziej optymalne, ale bedzie dzialac)
edit 2: a nie, czekaj, nie bedzie, bo chyba nie masz zamiennikow ToDouble() itp dla zwyklego std::string? czyli i tak trzeba bedzie pozmieniac odwolania do konwersji, bleh.

Pozostale 10% to zmiana wywolan typu
    TQueryParserComp *Parser;
    Parser = new TQueryParserComp(NULL);
    Parser->TextToParse = str;
    Parser->First();
na
    cParser *Parser;
    Parser = new cParser( str );
i juz. Jak sie skompiluje i pojdzie, to wtedy mozna sie bawic w zastapienie istniejacych odwolan do GetNextSymbol() na bardziej eleganckie itp.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 17 Listopada 2016, 20:41:35
Tak, chodziło mi właśnie o token += c. To jest kod jaki został podany za przykład na realokację za każdym wywołaniem. Wiesz, niektórzy tutaj napisali własne formaty plików, żeby przyspieszyć ładowanie. Masz różnice między 10min a 5min. Odwołaniami do ToDouble() nie ma co się przejmować. Albo zrobię klasę potomną do std::stringa z samymi funkcjami inline, albo po prostu pozmieniam. W końcu już w tylu miejscach pozmieniałem, że to nie problem jest.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 18 Listopada 2016, 00:59:31
Tak, chodziło mi właśnie o token += c. To jest kod jaki został podany za przykład na realokację za każdym wywołaniem.
Ah, ok. Akurat z tym to roznie bywa (dlatego nie rzucilo mi sie w oczy od razu), bo co prawda w standardzie tego nie ma, ale nowsze implementacje czesto stosuja cos, co nazywaja "Small String Optimisation", taki prywatny maly bufor wbudowany w string, na ktorym operuja najpierw, zeby uniknac alokacji. A przy wiekszych stringach re-alokacja tez jest wiekszymi kawalkami, zamiast co znak. Tak czy owak, z dodanym reserve() nie powinno byc tutaj problemow, nawet przy starszym kompilatorze.

edit: tutaj jest fajny artykul pokazujacy jak wyglada SSO w roznych kompilatorach: http://info.prelert.com/blog/cpp-stdstring-implementations
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 22 Listopada 2016, 09:31:29
Z tego co poczytałem to Borland powinien mieć zaimplementowane Copy-on-Write wraz z powiększaniem stringa o troszkę więcej niż alokacja. Więc teoretycznie im dłuższy string tym mniej powinno być do niego alokacji przy kolejnym dodawaniu znaków. Ale nawet patrząc teoretycznie to przy mnożniku 1.5 i średniej liczbie znaków koło 6 to liczba alokacji wynosi: 1 - alokowanie pustego stringa, 2 - pierwszy znak + drugi znak, 3 - 3,4,5 znak, 4 - 6 - 9 znak. To chyba niezbyt wydajne, żeby robić alokację 4-krotnie przy liczbie znaków 6-9? To reserve faktycznie powinno pomóc.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 22 Listopada 2016, 12:43:13
Włos mi się zjeżył na głowie jak przeczytałem o przydzielaniu pamięci dla pojedynczych znaków. Zgroza. (No chyba, że czegoś tu nie wiem).

Od jakiegoś czasu używam prywatnie parsera formatu MaSzyny do swoich celów (robię nowy, lepszy starter) - działa na zasadzie FSM-Lexer/Parser. Na razie wszystko mu jedno co jest w tych plikach, działa jako iterator, czyli od podpiętego modułu zależy, co do czego będzie parsował. Starter interesuje tylko niewielki podzbiór, więc ten podzbiór jest czytany, cała reszta jest ignorowana, w momencie jak przestanę ją ignorować, nie będą mnie obchodzić stringi w skryptach - dostanę gotowe obiekty. Przypuśćmy, że mam obiekt składający się po prostu ze współrzędnych X, Y, Z. Czyli strukturę z 3 double. Funkcja parsera "ParseVector()" pobierze 3 tokeny, sparsuje 3 stringi jako double i zapisze w strukturze. Do tego jest jeszcze parsowanie kolorów RGB, ścieżek do plików i czasów.

Jak tam to działa? Masz jeden blok pamięci z całym skryptem. Lexer analizuje za każdym krokiem 1 do 2 znaków skryptu. Znaczenie znaku jest interpretowane w zależności od stanu (int). Stan zmienia się w zależności od napotkanych znaków. Szybciej się nie da. Pierwsza faza (analiza leksykalna) rozdziela logicznie skrypt na "encje" (powiedzmy znaczące słowa), znaki rozdzielające i komentarze. Wynikiem tej fazy są wyłącznie offsety i długości w skrypcie. Biorąc "string" z takiego tokena z góry znasz jego długość. Dodatkowo każdy taki string możesz praktycznie zapisać dokładnie w tym samym przydzielonym 1KB (dałbym nawet 64KB, żeby zapas był). Oczywiście nie unikniesz "ToDouble()", ale przynajmniej nie będzie to zużywać bez porównania większego czasu na przydzielanie pamięci. Z doświadczenia wiem, że mało rzeczy jest wolniejszych od przydzielania. Jak pętla ma przejść po 100MB danych, w środku nie może być praktycznie żadnego przydzielania.

Gdybym potrzebował wydajności (optymalizacja czasu ładowania) - zapisałbym wynikowe obiekty jako binarki. Przykładowo "nazwa.scm => nazwa.bin", albo "katalog/nazwa.scm => "cache/nazwa.bin". I po krzyku. Pierwsze uruchomienie - ładowanie 5 minut, drugie uruchomienie ładowanie 10 sekund. Zastanowiłbym się nawet nad przepuszczeniem strumienia cache przez kompresor. Być może byłoby to szybsze niż ładowanie dłuższych plików nieskompresowanych.

Do tego nie trzeba n "własnych formatów". Dokładnie jeden ogólny. Wynikający ze struktury binarnej obiektu. Format definiuje struktura. Serializację gotowy serializer. Broń boziu pisać własny, szkoda czasu. Pierwsza faza ładuje, parsuje i cache-uje pliki. Dalej w kodzie nie powinno być już kompletnie nic związanego z parsowaniem. Koniecznie osobne przebiegi. Nie "parsuj linię, załaduj teksturę, parsuj kolejną", tylko "załaduj wszystkie skrypty (łącznie z include), przejdź do ładowania pozostałych zasobów". Mam nadzieję, że rozkłady jazdy mają wewnętrznie jakąś sensowną binarną reprezentację, bo parsowanie tych koszmarków "na żywca" musi być bardzo wolne.

Dla optymizacji można by pokusić się o własną wersję "ToDouble" - ignorującą masę przypadków brzegowych jak różne formaty liczb. Ale to słaba opcja, lepiej dopuścić w skryptach bardziej "poluzowaną" notację kosztem wydajności, a zapisywać binarki w cache. Do zrobienia: 1 ogólny format cache, testowanie aktualności przez porównanie dat plików.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 22 Listopada 2016, 14:51:53
Włos mi się zjeżył na głowie jak przeczytałem o przydzielaniu pamięci dla pojedynczych znaków. Zgroza. (No chyba, że czegoś tu nie wiem).
Raczej niezrozumienie jak dziala std::string. Zadna normalna/rozsadna implementacja nie przydziela pamieci dla pojedynczych znakow z osobna, nie ma co panikowac.

Dla zaspokojenia ciekawosci zrobilem sobie nastepujacy test:
// start
cParser parser( scenefile, cParser::buffer_FILE, subpath );
std::string token;
do {
token = "";
parser.getTokens();
parser >> token;

} while(token != "" );
// stop
i przepuscilem przez niego scenery/quarkmce.scn (w sumie na oko jakies 10mb tekstu) Calosc zajela ok. 1.7 sek, przy odczycie z normalnego, starego HDD. Wiec akurat nad wydajnoscia parsera bym sie nie spinal -- raczej nie jest on odpowiedzialny za ladowanie scen w 5-10 minut, i naweg gdyby Borland byl jakims sposobem kilka razy szybszy (nie moge skompilowac/sprawdzic) to i tak mowimy tu o roznicy wielkosci ulamka sekundy, w procesie ktory wykonuje sie raz na uruchomienie.

(zeby bylo smieszniej, przeniesienie zmiennej do naglowka itp nie ma realnego wplywu na predkosci testu; podejrzewam ze najwolniejszym elementem jest, tak jak mozna bylo sie spodziewac, samo ladowanie zawartosci plikow z dysku)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: El Mecánico w 22 Listopada 2016, 16:24:31
A czy aby wąskim gardłem tutaj nie będzie przeskakiwanie do funkcji ładujących elementy scenerii i czekanie za każdym razem na ich zakończenie? IMO, ładowanie elementów mogło by spokojnie latać w osobnych wątkach i operować na obiektach przygotowywanych z już określonym rozmiarem i zarezerwowaną pamięcią przed wywołaniem funkcji ładującej. Komunikacja przez semafory.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 22 Listopada 2016, 18:55:28
Jak najbardziej, z tym ze przy programowaniu wielowatkowym znacznie latwiej cos schrzanic niz zwykle, wiec troche trzeba przy tym uwazac. Dobrze byloby pewnie najpierw naprawic i uporzadkowac to, co jest, rozdzielic na jakies sensowne moduly i takie tam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 22 Listopada 2016, 19:32:52
Większym problemem przy parsowaniu pliku scenerii jest to, ze mamy mnóstwo braku trafień w cache, a związane z brakiem parsowania całego pliku naraz  a dopiero potem inicjacja obiektów. W tej chwili ładujesz plik tekstowy do zmiennej, coś na niej czytasz, robisz mnóstwo innych operacji przy okazji i co chwila nie trafiasz w cache procesora. Jak wracasz do parsowanego tekstu to już go w cache znowu nie ma i musisz go ściągać z pamięci głównej. Tylko, że nie wiem czy jest sens rozgrzebywać ładowanie scenerii kiedy działa. Chociaż z drugiej strony ładowanie kaliskiej na moim kompie to jakieś 20 min, więc może jest o co walczyć.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 22 Listopada 2016, 20:02:02
IMHO jest sens, ale nie teraz. Na początek potrzebna byłaby wersja exe identyczna z bieżącą oficjalną, tyle, że już bez Borlanda. To byłby dobry punkt wyjścia. Gdyby robić optymalizację exe przedtem - ten etap, kamień milowy pewnie mocno by się opóźnił w czasie. A tak, zanim się ruszy optymalizacje - można by poprawić bugi, czy dodać kilka mocno usprawniających symulację usprawnień. No i zawsze lepiej chyba optymalizować już co w 100% działa, nie?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: El Mecánico w 22 Listopada 2016, 20:14:40
Oczywiście, że jest o co walczyć. Sama konwersja z jednego systemu programistycznego do innego już sporo bałaganu narobiła, więc równolegle montowanie novum to tego (nowy branch) jest odpowiednim momentem.

Zastanawiam się nad jeszcze jednym rozwiązaniem problema: dla ładowania jako tako nie jest problemem zapis jednego elementu skryptu scenerii w jednej linii, więc... "zwijamy" wiersze, tniemy plik przy ładowaniu linijka po linijce, i w takiej kolejce popychamy do parsera. Kolejki obiektów na ogół nie są w całości cofane z cache, przynajmniej trochę z góry powinno zostać. Teraz dopiero przystępujemy do zasadniczej obróbki materiału. Rezerwujemy pamięć pod obiekt i zasadniczego konstruktora albo puszczamy w odrębny wątek, albo jeśli nie chcemy się w wielowątkowość bawić (shame!) czekamy aż konstruktor skończy i zgłosi gotowość.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 22 Listopada 2016, 21:45:17
IMHO jest sens, ale nie teraz. Na początek potrzebna byłaby wersja exe identyczna z bieżącą oficjalną, tyle, że już bez Borlanda. To byłby dobry punkt wyjścia.
Tez wydaje mi sie, ze najrozsadniej chyba byloby skupic sie najpierw na wykopaniu Borlanda do konca, a jak juz sie da skompilowac rezultat gdzie indziej, to mozna go puscic przez profiler i na podstawie tego robic optymalizacje tego, co faktycznie obciaza proces.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 23 Listopada 2016, 00:01:05
Z mojego doświadczenia wrzucanie czasochłonnych rzeczy do konstruktorów jest średnim pomysłem. Nie, żeby się nie dało, ale w C# przykładowo standardem jest puszczanie takich rzeczy jako dajmy na to LoadAsync, co oczywiście odpala się w równoległych wątkach, a potem można poczekać aż wszystkie skończą, czy też dowolnie pokolejkować przykładowo semaforami.
Ale to daleki strzał, i wg mnie dość prosta rzecz do zrobienia. Nie ma się co bawić przy tym formacie w linie, dla formatu EOL, spacja, tab czy średnik znaczą dokładnie to samo. To powinien (jak ma być naprawdę szybko) robić lexer, od tego jest. Oczywiście może sobie chodzić szeregowo w łańcuszku z parserem, a może nawet równolegle, ale to już trochę zabawy z synchronizacją. Ważne, żeby dane były sparsowane ZANIM symulacja w ogóle odpali, parsowanie podczas symulacji jest oddawaniem cykli CPU za darmo. Warto je przeznaczyć na ciekawsze zadania.

ALE: z tego co widziałem, przy ładowaniu scenerii i tak 99% czasu wydaje się zajmować ładowanie tekstur. Reszta się u mnie ładuje w kilka sekund. No chyba, że zielone okienko kłamie. Tekstury ładują się tak długo, bo na długiej trasie może być ich naprawdę sporo. Może i nawet musi. Im więcej tym lepiej. Im większe tym lepiej. Może tylko niekoniecznie powinny ładować się wszystkie na raz. Co się stanie z silnikiem Fallout 4 gdy spróbujemy załadować kilka kilometrów kwadratowych na raz? Albo chociaż spróbujemy przemieścić się z prędkością maksymalną EP09? Wysypie się. Tzn nie do Windowsa, po prostu się okrutnie przytnie, zawiesi na chwilę, bo musi sobie dograć tekstury. Tego normalnie podczas gry nie widać (dogrywają się dynamicznie).

I prędzej czy później to będzie w MaSzynie też potrzebne. Sprawdzanie jakie obiekty są powiedzmy w promieniu 2km, i te mają się dograć. OK, na początek i tak będą się musiały wgrać wszystkie co wyświetlają się przy starcie, ale potem będzie dość czasu na dogranie. To musi być rzecz jasna opcja, bo na muzealnym sprzęcie by zacinało. Ale na współczesnych komputerach spokojnie wszystko nadąży.

Tylko oczywiście nie teraz. Teraz wylatuje Borland, potem będzie parę szybkich bugów do usunięcia. I parę potrzebnych ficzerów do dodania. Optymalizacja ładowania to będzie wisienka na torcie ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 23 Listopada 2016, 13:12:25
Z mojego doświadczenia brak inicjacji w konstruktorze zmiennych, do których odwołanie odbywa się przez wskaźnik prowadzi wprost do wysypów w dziwnych i nieoczekiwanych okolicznościach.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 23 Listopada 2016, 14:06:54
Z mojego doświadczenia brak inicjacji w konstruktorze zmiennych, do których odwołanie odbywa się przez wskaźnik prowadzi wprost do wysypów w dziwnych i nieoczekiwanych okolicznościach.
No, tak sie konczy proba odwolania do czegos co nie jest gotowe :)  Ale to nie znaczy ze trzeba caly process przygotowania modelu robic w konstruktorze. Konstruktor moze np oznaczyc obiekt jako 'niegotowy' (I albo odpalic proces ladowania/obrobki albo zostawic to dla managera) a reszta kodu jest wtedy tresowana zeby tego nie tykac dopoki flaga gotowosci nie jest przestawiona.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 23 Listopada 2016, 18:42:03
I to mi się podoba. Konstruktor powinien inicjować wszystko co da się zrobić natychmiast. Czyli wszystkie zmienne, ale już nie obiekty większe od 1kB, te powinny być ustawione na jakieś null-e i być inicjowane kiedy są potrzebne, względnie w jakimś osobnym wątku inicjacyjnym.

Te rzeczy można nawet robić od razu, tzn bez kombinowania z wątkami na początku, niech będą sobie w osobnej funkcji typu Init lub Load, i niech to się odpala zaraz po konstruktorze. Jak zabangla, to można wtedy kombinować z przeniesieniem tych wywołań w bardziej optymalne miejsce.

Gorzej, jeśli przy tworzeniu obiektów nie wszystko jest sparsowane, to już jest węzeł do rozplątania.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 24 Listopada 2016, 10:05:48
Tylko powiedz mi czym różni się Kontruktor(); Init(); od wrzucenie wszystkiego do Konstruktor() ? Ja miałem wysypy bo konstruktor nie tworzył jakichś obiektów i wskaźniki były na NULL (gdyż autor poprawki nie wywołał nigdzie Init() ). Wole stworzyć nowy obiekt z domyślnymi wartościami, ale nie bawić się w jego obróbkę, gdyż jeśli ktoś coś potem zawali to nie mamy niespodziewanych wysypów w dziwnych miejscach. Już nie mówiąc, o całej klasie TMoverParameters, którą trzeba rozbić na wszystkie występujące przypadki, a nie wrzucać do jednego worka wszystkich możliwych fizyk i potem mamy if-y włącznie z takimi kwiatkami jak if(dt_et22) coś tam coś tam else coś tam dla reszty.
Ale wracając do inicjacji obiektów, to w tej chwili ja wolę to mieć w konstruktorze i być pewnym, że się coś nie sypnie, aczkolwiek większość obiektów ma wydzieloną funkcję Init() tylko, że jest to dalsza część konstruktora tak naprawdę i nie można używać tych obiektów dopóki ona nie zostanie wywołana. Używać rozumiem pod pojęciem, że wywołanie zwróci błędne dane, ale nie wysypie programu na odwołaniu do NULL.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 24 Listopada 2016, 15:52:30
Powinno wyglądać docelowo tak: if (krowa.dane != null) krowa.Init(); Brak null-checka w miejscu, gdzie obiekt może być jeszcze niezaładowany to po prostu bug. Tzn na razie może zostać, ale lepiej to później poprawić.

Przy czym jestem przeciwnikiem wszelkich technik "ukrywania błędów". Ludzie poświęcają zadziwiająco dużo energii, żeby nie dopuścić do sypania się apki podczas działania, ale omijają szerokim łukiem rzeczywiste programowanie defensywne, czyli takie, gdzie sama poprawność konstrukcji uniemożliwia sypanie kodu.

Mało tego, jestem za taką konstrukcją, która jak najbardziej wywali wyjątek, zamiast po cichu obejdzie czy zignoruje. Masz twardy wysyp - to widzisz gdzie jest bug i możesz go poprawić. Ale możesz to ukryć w ten sposób, że część rzeczy będzie śmigać, a część kiedyś tam się wysypie, jak już wszyscy zapomną od czego. Myślę, że niektóre zmienne powinny być wręcz jawnie ustawione na null, żeby posypało się wszystko co tylko może. Dzięki temu można wyłapać te miejsca i poprawić. Jasne, że nie ma sensu dawać null-checka w jakiejś pętli mielącej coś pierdyliard razy, ale domyślam się, że problem jest wyłącznie przy uruchamianiu, jak symulator startuje wszystko jest wgrane i gotowe. Swoją drogą byłoby fajnie też, żeby do wersji dla userów dać kilka try / catch w kluczowych miejscach i wysyłać wyjątki do logu. Jak ktoś zaliczy wysyp, to będzie mógł przynajmniej wysłać co się złożyło.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 25 Listopada 2016, 07:27:53
Yyyy.... Wiesz, raz mi się sypało na braku kabiny. Tylko nikt nie wie czemu kabina usunięta i załadowana w tej samej funkcji i przypisana do wskaźnika w następnym cyklu wskaźnik był ustawiony na null a w następnym już był przypisany. W innym przypadku sypało na braku przypisania nazwy do PowerSource w funkcji logowania przeciążenia stacji. Okazało się, że nazwa była przypisywana ręcznie do klasy (do zmiennej public) i w jednym miejscu tworzenia klasy to było zrobione a w innym nie. I teraz mi powiedz, że nie zrobienie tego w konstruktorze (kiedy mamy te dane) jest normalne i logiczne. Za to zgadzam się, że ładowanie pliku przez konstruktor to nie jest najlepszy pomysł.

  Dodano: 25 Listopada 2016, 07:32:22
Ahhh... A miałem coś powiedzieć z ciekawostek fizyki. Otóż w funkcji getVDc() mamy trzy bloki if-a. W ostatnim liczy różnicę przepływów przez połączenia do pojazdów. Cała funkcja obliczająca różnicę jest zestawem kolejnych mnożeń. Po środku nawet wołana jest funkcja klasy hamulca, jakieś sprawdzania maksimów. Po wyliczeniu wywoływane funkcje zmiany przepływów w pojazdach obok. Super prawda?
Szkoda tylko, że na końcu funkcji obliczającej różnicę jest wielkie * 0. Ktoś mi powie po co to wszystko wyliczać kiedy żadnych zmian nie będzie?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 25 Listopada 2016, 13:18:02
I teraz mi powiedz, że nie zrobienie tego w konstruktorze (kiedy mamy te dane) jest normalne i logiczne. Za to zgadzam się, że ładowanie pliku przez konstruktor to nie jest najlepszy pomysł.
Ale chyba nikt nie sugeruje, zeby w konstruktorze w ogole nic nie robic? Tylko zeby rozdzielic takie rzeczy jak np proste ustawienie wartosci dla stringa z nazwa (konstruktor) z jednej strony, a ladowanie i obrobka siatki 3d powiazanej z modelem (init/load/whathaveyou)

Ale tak przy okazji, to jesli chodzi o te przyklady, to 1) z kabina, to wlasnie jest raczej przyklad tego, ze nie ma co na slepo odwolywac sie do obiektu bez sprawdzenia czy nie jest on czasem ustawiony na null -- tutaj taki test albo kontrolowany wysyp duzo latwiej byloby wysledzic 2) to oczywiscie powinno byc zrobione w konstruktorze; ale nawet jesli nie bylo, to wysyp mial raczej miejsce dlatego, ze domyslnie  w ogole nie bylo tam nic przypisane, a na zdrowy rozum powinno to byc cos jak "unspecified class" albo nawet pusty string, ale /jakis/ string a nie dziura do pamieci, ktorej glupi komputer od stringa nie odroznia :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 25 Listopada 2016, 20:34:40
Ja w konstruktorach ustawiam zmienne, ale nie robię następujących rzeczy: operacji wejścia / wyjścia, iteracji dużych zbiorów.
Te rzeczy zostawiam dla funkcji asynchronicznych. Sprawdzałem przed chwilą: w C++ jest w miarę sensowna obsługa tego.
Jak wielowątkowość może przyśpieszyć program to wiesz. A nie ma specjalnie dużo więcej pisania. Potem masz swobodę poukładania sobie, co się musi wgrać pierwsze, co musi poczekać, a co może się inicjować jednocześnie. Oczywiście to wymaga porządku w kodzie. Zawsze musisz sprawdzić, czy dane w konkretnym punkcie są już dostępne. Albo wołać operację na danych, kiedy masz pewność że masz dane (bo poczekałeś na wątek inicjujący). No i masz potem czasem przypadek, że nie musisz nawet czekać, bo wątek zdążył skończyć. Czysty zysk w takim przypadku.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: youBy w 25 Listopada 2016, 23:02:57
Ahhh... A miałem coś powiedzieć z ciekawostek fizyki. Otóż w funkcji getVDc() mamy trzy bloki if-a. W ostatnim liczy różnicę przepływów przez połączenia do pojazdów. Cała funkcja obliczająca różnicę jest zestawem kolejnych mnożeń. Po środku nawet wołana jest funkcja klasy hamulca, jakieś sprawdzania maksimów. Po wyliczeniu wywoływane funkcje zmiany przepływów w pojazdach obok. Super prawda?
Szkoda tylko, że na końcu funkcji obliczającej różnicę jest wielkie * 0. Ktoś mi powie po co to wszystko wyliczać kiedy żadnych zmian nie będzie?
Trzeci blok ifa został z czasów kalibracji przepływów. Koniec końców okazało się, że bez tej części symulator działa najlepiej – nie posprzątałem po sobie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: El Mecánico w 26 Listopada 2016, 14:20:54
IMO konstruktor powinien skończyć robotę jak najszybciej i tylko przygotować zestaw zmiennych dla kolejnych funkcji ładujących, czyli poinicjalizować wskaźniki na null, powpisywać nazwy plików (bez ich otwierania) i wrócić do miejsca wywołania. Tak wstępnie powstałe obiekty wypadało by posortować pod względem istotności dla _rozpoczęcia_ symulacji i w takiej kolejności ładować grube dane. Pierwsza pewnie komórka (komórki) scenerii na której znajduje się nasz pojazd/skład, potem w odległości wyświetlania, uzależnienia/sterowanie w tej lokalnej komórce. Całą resztę scenerii można załadować w tak minimalnej postaci jak tylko to możliwe i konieczne do obliczenia dynamiki i interakcji pojazdów, czyli pomijając całe modelowanie. Na to czas będzie nawet już w czasie symulacji. Generalnie fizyka i grafika powinny być w zależności podległej (grafika wyświetla dopiero jak fizyka policzy), bez pobierania z grafiki jakichkolwiek danych, nawet synchronizacji. Grafika powinna liczyć na _kopii_ danych otrzymanych od fizyki, żeby nie było, że między początkiem a końcem tworzenia klatki fizyka podmieni dane.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 27 Listopada 2016, 13:11:06
W tej chwili na pewno fizyka nic nie podmienia, gdyż jest liczona w każdej klatce na nowo. Stąd były takie problemy, że jeśli FPS spadał zbyt bardzo to cuda zaczynały się dziać z zachowaniem składów. Tamtego if-a w GetVDc zakomentowałem. Zresztą nie tylko tam bo było jeszcze parę miejsc gdzie były if-y prowadzące np. do zakomentowanych funkcji, chyba najlepszym miejscem były trzy if-y po kolei sprawdzające jakieś tam rzeczy po czym we wszystkich odnogach każda potencjalnie wywoływana funkcja była zakomentowana w związku z czym exe po zrobieniu iluś branchy (z każdym traci cykle pracy) nie robiło nic.

  Dodano: 29 Listopada 2016, 20:12:18
Pogadaliśmy sobie troszkę, a ja tu pracuję ;)
Z placu boju to teraz sprawdzam każdą funkcję w moverze i poprawiam, uzupełniam braki i ewentualnie usuwam niepotrzebne rzeczy, np coś takiego:
PosRatio = -PosRatio * 0;albo takiego
PosRatio = 1.0 * (PosRatio * 0 + 1) * PosRatio; // 1 * 1 * PosRatio = PosRatio.
Właśnie skończyłem tracktionforce i zaczynam brakeforce. Idzie do przodu. Narazie commitów nie wrzucam na serwer bo to bez sensu jest. Wrzucę wszystko jak skończę i będzie można skompilować.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: El Mecánico w 29 Listopada 2016, 21:05:27
W tej chwili na pewno fizyka nic nie podmienia, gdyż jest liczona w każdej klatce na nowo. Stąd były takie problemy, że jeśli FPS spadał zbyt bardzo to cuda zaczynały się dziać z zachowaniem składów.[ciach]

No i dlatego fizykę wypadało by z tego oczekiwania wybić i ograniczyć częstotliwość przeliczania do arbitralnej liczby max 120 powtórzeń na sekundę. Wyniki obliczeń fizycznych wystawiać na kontener, a grafika na początku każdej klatki robiła by sobie szybką kopię na własne potrzeby.
Wiem, na starszych komputerach było to marnowanie mocy obliczeniowej, która przydawała się w obliczaniu grafiki, ale dzisiaj nic nie tracimy. A jak kiedyś byśmy chcieli pomyśleć o multi, to bez tego się nie obejdzie...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 29 Listopada 2016, 23:11:05
No i dlatego fizykę wypadało by z tego oczekiwania wybić i ograniczyć częstotliwość przeliczania do arbitralnej liczby max 120 powtórzeń na sekundę.
120 to bylby tzw overkill -- w zasadzie wszystkie gry publikowane dzisiaj maja fizyke liczona 15-20 razy na sek., okazjonalnie moze 30/sek. Silnik trzyma sobie zapisana aktualna i poprzednia kalkulacje, i interpoluje miedzy nimi na potrzeby wizualizacji.

tutaj jest bardzo ladna seria artykulow na ten temat: http://gafferongames.com/game-physics/ z kodem c++ i mnostwem innych przydatnych rzeczy (jak np. fizyka typu klient-serwer, bardzo przydatna do multiplayera itp)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 30 Listopada 2016, 13:02:54
Ja tam uważam, że już na początek samo zrobienie osobnej fizyki do wagonów będzie powodowało mniej miss-cache (w tej chwili każdy wagon przechowuje wszystkie zmienne każdego możliwego typu napędu). Tych danych jest na tyle dużo, że bez sensu jest trzymanie ich niepotrzebnie w każdym obiekcie. Jeśli jeszcze samo rozseparowanie wagonu on lokomotywy zrobi się zgodnie z Data Oriented Programming to można pewnie przyspieszyć obliczanie fizyki z dwa razy.
Widzę tutaj jednak pewną problematyczną sprawę, że w fizyce jest mnóstwo miejsc kiedy obiekty wywołują siebie nawzajem. Być może da się zredukować niektóre z tych wywołań do obliczeń na jednej macierzy danych dla większości obiektów.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: youBy w 30 Listopada 2016, 16:37:02
No i dlatego fizykę wypadało by z tego oczekiwania wybić i ograniczyć częstotliwość przeliczania do arbitralnej liczby max 120 powtórzeń na sekundę.
120 to bylby tzw overkill -- w zasadzie wszystkie gry publikowane dzisiaj maja fizyke liczona 15-20 razy na sek., okazjonalnie moze 30/sek. Silnik trzyma sobie zapisana aktualna i poprzednia kalkulacje, i interpoluje miedzy nimi na potrzeby wizualizacji.
U nas fizyka musi być liczona z krokiem nie większym niż 100 razy na sekundę ze względu na stabilność sprzęgów i przepływów.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: El Mecánico w 30 Listopada 2016, 21:54:51
No i to 100 to i tak może być dużo, albowiem wiele gier i aplikacji 3D ma w opcjach przełącznik ograniczający częstotliwość wyświetlania do 60 klatek (chociaż 50-55 jest dla ludzkiego oka płynne).
Za czasów świetności Delphi nie było jeszcze wzorców, stąd zapewne wszystkie dynamic'i przechowują komplet zmiennych dla wszystkich typów napędu. Znowu pole do orania (yy, do popisu :D) i przerobienie budowania obiektów dynamic wg wzorców i ograniczanie ilości danych i metod to rzeczywiście używanych w danym typie pojazdu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 01 Grudnia 2016, 00:43:52
U nas fizyka musi być liczona z krokiem nie większym niż 100 razy na sekundę ze względu na stabilność sprzęgów i przepływów.
Nie jestem pewien czy dobrze to czytam, ale czy masz na mysli ze fizyka musi byc liczona co najmniej 100 razy/sek? Czy przeciwnie, nie wiecej niz 100 razy? Jesli to pierwsze, to chyba raczej w tej chwili nie ma to miejsca jesli fizyka jest liczona raz na ramke graficzna, bo 100 fps raczej rzadko sie zdarza, nawet przy wylaczonym vsync (no chyba ze kalkulacje sa robione z malym krokiem tyle razy ile trzeba, co ramke graficzna, ale wtedy nie wariowaloby przy niskim framerate?)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: matek123 w 01 Grudnia 2016, 07:36:35
" nie większym niż 100" czyli maksymalnie 100 kroków w sekundę.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 01 Grudnia 2016, 12:40:17
" nie większym niż 100" czyli maksymalnie 100 kroków w sekundę.
Ale tam bylo "z krokiem nie wiekszym niz", i zaczalem kombinowac, ze to wskazuje ze krok musi byc jak najmniejszy, a to akurat zwieksza ilosc kalkulacji na sekunde, a nie zmniejsza :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 02 Grudnia 2016, 08:11:48
Za czasów świetności Delphi nie było jeszcze wzorców, stąd zapewne wszystkie dynamic'i przechowują komplet zmiennych dla wszystkich typów napędu. Znowu pole do orania (yy, do popisu :D) i przerobienie budowania obiektów dynamic wg wzorców i ograniczanie ilości danych i metod to rzeczywiście używanych w danym typie pojazdu.
Nie zgodzę się, gdyż cały SPKS ma zrobione hamulce na obiektach i pochodnych a pierwotnie napisany był w Delphi. Więc dany obiekt nie przechowuje niepotrzebnych danych.
Ja widzę raczej problem, że funkcje w jednym obiekcie wywołują te same funkcje w następnym obiekcie i to powoduje przeładowanie wszystkiego w pamięci. Brakuje trzymania pociągu w kontenerze (tzn kontener jest ale do tego nie służy), z którego pobierane są dane wspólne, np. komendy rozsyłane po składzie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: youBy w 02 Grudnia 2016, 17:37:57
Nie jestem pewien czy dobrze to czytam, ale czy masz na mysli ze fizyka musi byc liczona co najmniej 100 razy/sek? Czy przeciwnie, nie wiecej niz 100 razy? Jesli to pierwsze, to chyba raczej w tej chwili nie ma to miejsca jesli fizyka jest liczona raz na ramke graficzna, bo 100 fps raczej rzadko sie zdarza, nawet przy wylaczonym vsync (no chyba ze kalkulacje sa robione z malym krokiem tyle razy ile trzeba, co ramke graficzna, ale wtedy nie wariowaloby przy niskim framerate?)
Dokładnie tak jest - jeśli czas wygenerowania ramki graficznej przekroczył 10 ms, wtedy fizyka jest liczona wielokrotnie, żeby czas jednej iteracji fizyki nie przekroczył 10 ms. Przy ekstremalnie niskim fps (poniżej 5) fizyka jest liczona najwyżej 20 razy na klatkę, co skutuje spowolnieniem upływu czasu w symulacji.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 02 Grudnia 2016, 23:35:39
Skończyłem poprawiać cały TMoverParameters. Mam nadzieję, że niczego nie przeoczyłem. Udało się też skompilować projekt. W związku z tym poprawki wrzuciłem na repo. Jutro testy odpalania czy to wszystko w ogóle będzie działać.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 03 Grudnia 2016, 12:19:28
Zapodasz skompilowany efekt pracy?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 03 Grudnia 2016, 19:17:16
Niestety nie, gdyż nie ma czego zapodawać. Nadal występują błędy obsługi hamulców. Ponadto wsadza mechanika nie do tej kabiny i próbuję w tej chwili dojść dlaczego.

  Dodano: 03 Grudnia 2016, 20:08:44
Czemu była nieprawidłowa kabina już znalazłem. Ale błąd jest dziwny i muszę rozgryźć dlaczego funkcja znajdowania w stringu nie działa prawidłowo. Za to hamulec jest spowodowany włączeniem flagi działania AI pomimo narzuconej obsady. Pewnie też coś w ten deseń jak poprzednio. Przejście z Borlanda na VS to nie będzie łatwa i przyjemna droga widzę.

  Dodano: 03 Grudnia 2016, 20:22:11
Dobra, znalazłem dwa błędy odnośnie inicjacji mechanika i już teraz ładuje dobrą kabinę. AI się włącza bo uruchamiam w debug. <facepalm>. Teraz odkrywanie czemu nie reaguje na klawisze hamulców.

  Dodano: 05 Grudnia 2016, 10:28:20
Znalazłem już przyczynę braku reakcji na hamulce. FV4aM działa. Teraz jeszcze tylko reszta kranów. Następnie będziemy sprawdzać, czy hamulce dobrze działają bo mam wątpliwości. Następnie, czemu po wrzuceniu pierwszej pozycji nastawnika nie pojawia się prąd na silnikach. No i widać, że nie ma co wydawać jak narazie.

  Dodano: 06 Grudnia 2016, 08:00:12
Nie mogę dojść do ładu i składu z hamulcami. Po przestawieniu kranu hamulec w ogóle nie reaguje. Sprawdziłem czy może uruchamia funkcje z klasy bazowej zamiast potomnej ale wygląda ok. Zaczynam głupieć.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: djuzi w 06 Grudnia 2016, 11:05:19
Grzesiek...porwałeś się na te hamulce. Czasem lepiej zostawić to na kilka dni i zająć się czymś innym. Póżniej gdy się wróci do tego na świeżo będzie dużo prościej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 06 Grudnia 2016, 12:40:08
No jak hamulce trykną, to można w zasadzie już wydać to nowe exe, chyba, że jeszcze jakieś regresje są w stosunku do borlandowego exe. Później warto by się zastanowić które bugi i w jakiej kolejności wziąć na tapetę. Z mojej strony głosowałbym na ten, który kładzie symulator po odwołaniu do nieistniejącej komórki pamięci. To powinno zapisywać normalnie komunikat do error.txt i ignorować polecenie. Ludzie piszą, że Kaliska się składa od czasu do czasu, ja jeszcze nie testowałem, ale gdyby po testach mieć  wpisy w error.txt zamiast wysypów byłoby łatwiej znaleźć przyczyny błędów, bo teraz niektórzy piszą, że sypanie na Kaliskiej wynika z błędów exe, a całkiem możliwe, że to błędy skryptów, tylko trudno to póki co odróżnić.

Drugi w kolejności do zaatakowania (IMHO) byłby ten, że syk hamulców (i ogólnie dźwięki) zawieszają się, kiedy nagle oddalimy się od źródła dźwięku. Np stoję przy syczącym wagonie na końcu długiego składu i wciskam F4 - ten syk się wtedy nie wycisza, jest zawieszony, żeby go "odwiesić" muszę jeszcze raz podejść do tego samego wagonu i powoli od niego odejść. Niestety jeśli źródłem dźwięku nie jest nasz skład, tylko inny, który sobie już odjechał, to ciężko odwiesić, bo trzeba by znaleźć źródło.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 06 Grudnia 2016, 13:20:04
Nie wydać chyba, raczej pokazać. Może nawet w zamkniętym dziale. Zbyt szeroka dyskusja rozmydli problemy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 06 Grudnia 2016, 15:22:54
Nie mogę dojść do ładu i składu z hamulcami. Po przestawieniu kranu hamulec w ogóle nie reaguje. Sprawdziłem czy może uruchamia funkcje z klasy bazowej zamiast potomnej ale wygląda ok. Zaczynam głupieć.
Jesli mozna cos zasugerowac, wytnij najpierw Borlanda do konca, a jak juz zrodla da sie skompilowac gdzie indziej, to i odpluskwianie i cala reszte bedzie duzo latwiej przeprowadzic.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 07 Grudnia 2016, 19:07:56
Najpierw to musiałem wyciąć taki fajny błąd, który powodował że nie dało się nic testować na debugerze w 9 na 10 przypadków. Po prostu symek się zawieszał. Po całym dniu szukania znalazłem, tą fajną różnicę, że Pascal inicjuje zmienne do wartości 0, a c++ jak chce. Więc jak nie zainicjujesz zmiennej, której potem nigdzie nie modyfikujesz przed pierwszym użyciem (w tym konkretnym przypadku przesunięcie taboru) to dziwne rzeczy się dzieją (np. dL = 1.38e+220) no i skład się próbuje ciągle przesunąć.
Tak ostatnio myślałem czy by nie wyciąć Borlanda do końca, ale musiałby się chyba znaleźć jakiś chętny co by wydziergał QueryParserComp z brancha. Jak się jakiś chętny znajdzie to resztę już i tak robię.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 07 Grudnia 2016, 21:16:58
Po całym dniu szukania znalazłem, tą fajną różnicę, że Pascal inicjuje zmienne do wartości 0, a c++ jak chce.
No, to akurat standard :)  Tzn nie, ze c/c++ inicjalizuje jak chce, tylko samo z siebie nie inicjalizuje w ogole, wiec dostajesz to co sie akurat trafi w pamieci, a trafic moze sie wszystko (przynajmniej w trybie release, debug moze sobie rozne rzeczy tam ustawiac)

Jak zrobisz wszystko inne, to jesli nie znajdzie sie nikt inny to ja moge sie poswiecic i tego parsera wyciac, ale to na samym koncu bo tak jak wspomnialem, inaczej nie bede w stanie tego skompilowac, wiec musialbym edycje na sucho robic.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 07 Grudnia 2016, 21:30:52
Ja ci borlanda udostępnię jak coś. Zawsze możesz go zainstalować na wirtualce (cd xp sp3 też się znajdzie).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 07 Grudnia 2016, 22:11:13
Tak szczerze to ja nie chce dranstwa tykac, bo nie mam zaufania ani do siebie ze czegos przy okazji nie spieprze, ani do niego ze mi w system jakos nie napaskudzi :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 08 Grudnia 2016, 08:37:14
No właśnie dlatego mówię o wirtualce. Jak dla mnie na sucho też może być.

  Dodano: 08 Grudnia 2016, 08:46:01
Okazuje się, że w hamulcach mam dziurę w przewodzie sterującym. Teraz szukam miejsca rozszczelnienia.

  Dodano: 08 Grudnia 2016, 18:11:53
Nie powinienem się brać za konstrukcję kranów bo źle podłączyłem i miałem tam wielką dziurę. Już załatana i wygląda, że powietrze mi narazie nie ulatuje. Teraz jakieś testy tego ustrojstwa i patrzymy co nie działa dalej.

  Dodano: 08 Grudnia 2016, 22:28:12
Znalazłem kolejną dziurę i teraz działa także sprężarka ;) Nie ma jak błąd w globalnej funkcji ustawiającej bity w zmiennej.
Teraz skład sam luzuje. Ciekawe gdzie znajdę ten feature, który to powoduje.

  Dodano: 10 Grudnia 2016, 19:57:33
Wygląda, że znalazłem dziurę w hamulcach. Takie zabawy są bez sensu. Trzeba przeglądnąć całe hamulce i dopisać inicjację wszelakich zmiennych w konstruktorze.

  Dodano: 10 Grudnia 2016, 22:52:17
Dziury już nie ma. Szkoda tylko, że po zmianie pozycji hamulca na jazdę przewód sterujący nie napełnia się do końca. W związku z czym hamulce też nie puszczają do końca. Pochlastam się chyba. W takim tempie to nie skończę tego do końca przyszłego roku.

  Dodano: 12 Grudnia 2016, 19:39:51
Narazie żadnych postępów. Nie wiem jak będzie w najbliższym czasie, gdyż w małopolsce poprawa komunikacji na linii do Tarnowa polega na wycięciu co drugiego pociągu w szczycie dla większości miejscowości. W związku z tym szansa, że sobie rano siądę z lapkiem spadła z 95% do mniej więcej 0%.

  Dodano: 14 Grudnia 2016, 08:14:03
Nie mogę znaleźć tego co jest źle. Na pewno coś się źle liczy tudzież sprawdza, ale nie wiem gdzie. Następny krok: nauczyć się jak uruchomić debugera dla kodu pascalowego (mam nadzieję, że nie będzie trudne) i sprawdzić na starej wersji jak się to wszystko liczy. Ogólnie już w pierwszym kroku obliczeń są różnice w ciśnieniach więc na pewno coś jest nie halo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: El Mecánico w 14 Grudnia 2016, 18:17:56
W ustawieniach kompilatora upewnij się, że nie ma optymalizacji na szybkość (-Ocyfra), zostaw ew optymalizację na rozmiar kodu (-Os). Jeśli dalej będą problemy, wyłącz też optymalizację na rozmiar.

  Dodano: 14 Grudnia 2016, 19:51:26
Jeśli to się uda, to będziemy potem szukać gdzie rzutować z volatile: http://stackoverflow.com/a/2219839 (http://stackoverflow.com/a/2219839)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 15 Grudnia 2016, 01:55:39
Ogólnie już w pierwszym kroku obliczeń są różnice w ciśnieniach więc na pewno coś jest nie halo.
Warto tez pewnie zweryfikowac czy kod dostaje te same dane wejsciowe, jeszcze przed obliczeniami -- wspominales nieinicjalizowane zmienne, wiec moze sie jeszcze jakies takie kwiatki ostaly.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 15 Grudnia 2016, 06:53:23
Ranna sesja poszła na checkout 481 i debug zmiennych nadawanych i otrzymywanych w funkcjach UpdatePipePressure i UpdateSecondPipePressure. Jak się uda usiąść po południu to zrobię to samo dla wersji c++ i zobaczę co tam się oblicza. Trochę robota głupiego ale nie mam wyjścia. Zastanawiałem się, czy aby nie przyspieszyć sobie tego przez sklonowanie repo. Muszę sprawdzić, czy można trzymać jednocześnie dwa BCB otwarte.

  Dodano: 17 Grudnia 2016, 16:43:42
No i pudło. Te dwie funkcje jak na razie liczą identycznie. Ładnie się zaczyna. Teraz będzie przerwa bo wróciła mi fucha do poprawek (po pół roku, jak ja to uwielbiam) więc narazie więcej nie potestuję. Jak ktoś ma ochotę to sprawdzić to przyjmę każdą pomocną dłoń.

  Dodano: 19 Grudnia 2016, 09:05:13
Stwierdziłem, że podejdę do tematu troszkę inaczej. Przygotowałem sobie nową wersję DynObj, która po każdym przeliczeniu fizyki w Mover->ComputeMovement wyrzuca do loga obliczone wartości PipePress, ScndPipePress, EqvtPipePress, BrakePress i CntrlPipePress. Jak po południu będzie czas to krótki zrzut do loga i patrzymy gdzie zacznie liczyć źle.

  Dodano: 20 Grudnia 2016, 07:13:16
No i dowiedziałem się tyle, że źle inicjowana jest wartość ciśnienia w hamulcach. Rano poprawiłem i sprawdziłem przy okazji całą funkcję i też zrobiłem poprawki (ale nie miały wpływu na te testy, na inne pewnie by miały). Po południu kolejne testy.

  Dodano: 20 Grudnia 2016, 19:25:41
Ha, znalazłem gada. Jednak debugowanie pascala ma swój głęboki sens. Funkcja Init hamulców uruchamia funkcje Init klas-matek. To teraz będzie łatwiej. Ciekawe co jeszcze ciekawego znajdę.

  Dodano: 21 Grudnia 2016, 07:20:10
Rano poprawiłem klasy hamulców. Jeszcze nie testowałem. Jak będzie ok to na tapetę idzie rozruch pojazdu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Mariusz1970 w 21 Grudnia 2016, 16:32:23
Wg mnie, przydałoby się jeśli nie masz jakieś narzędzie  do sprawdzania zmiennych np. ich inicjacji, ich wykorzystania, sprawdzania jakiś klas,  w danych funkcjach, procedurach, modułach itp. w zależności od zasięgu zmiennych. Ja na swój użytek, napisałem sobie własne narzędzie do sprawdzania kodu. Różne rzeczy mi sprawdza m.in. to powyższe. Ogólnie, mimo, iż trochę czasu zajeło napisanie narzędzia, opłacało się. Różne kwiatki wychodziły np. dana zmienna była zadeklarowane i zainicjowana, lecz jej później nie wykorzystywałem (ot sobie taka była niepotrzebna). Czasami z tego własnego narzędzia korzystam, przy jakiś złożonym długim kodzie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 21 Grudnia 2016, 19:31:15
Ale ten błąd był po części winą konwertera, którego użyłem a po części moją, gdyż nie znam Delphi i jak czegoś nie wiem to muszę najpierw sprawdzić co to robi. W c++ wywołanie funkcji z klas-matek odbywa się jawnie (tzn. musisz napisać kod uruchamiający konkretną funkcję) a w Delphi definiujesz przynajmniej na dwa różne sposoby stosując słowo kluczowe, którego nazwa nie jest dla mnie oczywistym uruchomieniem funkcji. Do tego w jednym przypadku robisz to globalnie dla wszystkich funkcji potomnych.
Dla C++ istnieją analizatory kodu więc nie ma potrzeby tego pisać samemu. Nie chcę teraz tego robić, ale na pewno znajdą mnóstwo zmiennych nieużywanych nigdzie. Dodatkowo Q dorzucił troszkę zmiennych używanych jednokrotnie ale tego nie tykam (bo działa) póki nie będzie działać cała reszta.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Mariusz1970 w 21 Grudnia 2016, 20:33:27
Ja mialem na mysli nie tylko ten blad, lecz jakies opisane w tym watku. Czyli wychodzi na to, ze sa analizatory, ale nie wiem, czy je uzywasz. Chyba nie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 22 Grudnia 2016, 08:52:48
Nie używam, gdyż na obecnym etapie to jest bez sensu. Kod movera jest tak scalony, że najpierw go trzeba rozdzielić, a dopiero potem można bawić się w analizę czy jest coś nieoptymalnego typu nieużywane zmienne. Chociaż być może znalazłyby się miejsca, gdzie mamy wysypy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Mariusz1970 w 22 Grudnia 2016, 09:14:34
Ok, to szukaj dalej na piechote np. nie zaincjowanych zmiennych z ktorymi miales zdaje sie problemy i straciles sporo czasu na identyfikacje problemu a to juz na tym etapie daloby sie zidentyfikowac albo poprzez gotowy albo wlasny analizator. Jesli chodzi o nieuzywane, to czesciowo juz mozna identyfikowac np. zmienne ktore sa hermetyczne w danej funkcji. Mialbys juz czysta nowa dodana funkcje, ale skoro twierdzisz, ze analizatory na tym etapuie sa bez sensu, ok. Ja nie zamierzam Cie uszczesliwiac na sile. Masz swoj styl pracy, swoje zasady, trzymaj sie ich :).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 22 Grudnia 2016, 10:51:00
Problem nie leżał w tym, że zmienna nie była inicjowana w ogóle. Była. Tylko nie w konstruktorze a w funkcji inicjującej, i nie w klasie budowanej tylko w klasie matce. To było łatwo znaleźć. Większym problemem było zorientowanie się, że źle inicjowane są wartości poprzez brak uruchomienia funkcji klas matek (a nie nie inicjowane w ogóle). Tego żaden analizator mi nie znajdzie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Mariusz1970 w 22 Grudnia 2016, 11:21:27
Byc moze, jednak nie wierze, aby nie dalo sie wymyslic analizatora te takie rzeczy, jesli jest warte zaintersesowania.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 22 Grudnia 2016, 11:35:18
No, tylko analizator nie sprawdzi czy jest potrzeba uruchomienia danej funkcji. Może Ci sprawdzić czy robisz to optymalnie. Ale żeby nie było, żem beton (ciekawe czy Kuba się będzie rzucał), to szukam jakiegoś dobrego narzędzia i może w święta zrobię analizę. Jak będą oczywiste błędy to można poprawić, ale nie chcę grzebać w nowych miejscach jeśli jest rozgrzebane coś takiego jak cała fizyka.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 22 Grudnia 2016, 13:37:17
Ale żeby nie było, żem beton (ciekawe czy Kuba się będzie rzucał), to szukam jakiegoś dobrego narzędzia i może w święta zrobię analizę.
Dla swietego spokoju mozesz kod przepuscic przez http://cppcheck.sourceforge.net/ zdaje sie ze jest calkiem przyzwoity i nie wymaga jakiegos specjalnego zaangazowania. Pisanie na wlasna reke jakis dedykowanych narzedzi raczej mija sie z celem, imo.

  Dodano: 22 Grudnia 2016, 15:57:28
Przepuscilem to co jest na githubie przez cppcheck, i troche kwiatkow znalazl, w tym kilka grubszych. Te z kategorii (error) trzeba by raczej poprawic, reszta to juz roznie. Czesc jest bardziej powazna, czesc mniej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 22 Grudnia 2016, 21:32:33
O, miło. Zerknąłem. Te z plików hamulce i Oerlikon są już nieaktualne. Tylko tych commitów nie wrzuciłem jeszcze na github-a. Chcę to jeszcze przetestować w wersji trial, któregoś z tych dużych komercyjnych analizatorów.

  Dodano: [time]23 Grudnia 2016, 10:33:42[/time]
No i hamulce dalej nie działają tak jak trzeba. Lok nie luzuje. Jakaś masakra. Mam teraz 20k logów do porównania i będę szukał, gdzie to się sypie. Przez święta raczej postępów nie będzie bo wyjeżdżam.

  Dodano: 29 Grudnia 2016, 07:52:25
Jak narazie udało się rzucić okiem na logi i wychodzi, że ciśnienie w przewodzie głównym (???) - zmienna PipePress nie podnosi się tak samo wysoko jak w wersji paszczalowej. Przepływ z przewodu zasilającego jest teoretycznie kontrolowany przez Handle->GetPF() i wygląda, że wracam do tematu implementacji tablicy wartości przepływu dla poszczególnych pozycji kranu. Może dzisiaj coś więcej zrobię wieczorem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 30 Grudnia 2016, 08:08:11
Nosz wkurzyłem się. Błąd był spowodowany nieprawidłowym użyciem przez kompilator funkcji abs(). Zamiast używać tej z cmath używał z stdlib (pomimo includowania nagłówka). A w stdlib jest wersja tylko dla int, a funkcja używa wersji dla double. Więc obliczał sobie double a potem niejawnie, bez ostrzeżenia , rzutował na int (co w tym przypadku oznaczało, że zamiast 0.xxxx było 0). I w konsekwencji zbiornik sterujący w kranie się nie wypełniał.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 30 Grudnia 2016, 09:51:14
Język Szatana! Ten problem to nawet jest popularny, programiści C++ lubią opisywać podobne przypadki na blogach. Ten język to jedno wielkie pole minowe.
To co, koniec blisko?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 30 Grudnia 2016, 10:45:50
Nosz wkurzyłem się. Błąd był spowodowany nieprawidłowym użyciem przez kompilator funkcji abs(). Zamiast używać tej z cmath używał z stdlib (pomimo includowania nagłówka). A w stdlib jest wersja tylko dla int, a funkcja używa wersji dla double.
Z tego co widze w zrodlach to kompilator dzialal tutaj poprawnie -- abs() z <cmath> jest ulokowany w namespace std, czyli zeby go uzyc trzeba wywolac std::abs() a w kodzie jest tylko abs(). No i jakies ostrzezenie przy kompilacji powinno tam byc, chocby dlatego ze parameter typu double jest konwertowany do int na wejsciu. Nawiasem mowiac ten sam blad ma miejsce przy innych funkcjach -- jest tam np. sqrt() zamiast std::sqrt()

Jak juz przy tym jestesmy, to w std:: sa tez min() and max(), mozna nimi zastapic te z mctools. Sa o tyle wygodniejsze, ze dzialaja na wszystkich typach zmiennych wiec nie trzeba pamietac ktory wariant jest do int, a ktory do double, itp.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 30 Grudnia 2016, 10:53:03
Najlepsze, że VS, którego używam jako IDE poprawnie łapie funkcję z double. Sprawę rozwiąże pewnie using namespace std;Teraz nie chcę się bawić w dostosowanie do użycia STL wszędzie gdzie się da, bo to nie jest ten etap. Teraz to ma działać. Czy koniec to nie wiem. Poprzednio kojarzę, że mogłem odhamować, ale już nie ruszyć ;) Więc wszystko po kolei.
Apropos szatana, to informatyka idealnie podpada pod definicję antychrysta ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Cesky Kretek w 30 Grudnia 2016, 11:45:15
Jestem pełen podziwu dla Twojej wytrwałości. Coś czuję, że po zakończonej transformacji trzeba będzie zrobić duuużą zrzutę na forum na jakiś prezent w ramach wdzięczności. :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 30 Grudnia 2016, 12:54:51
W stosunku do średniej wytrwałości twórców tras to narazie to słomiany ogień.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: surgeon w 30 Grudnia 2016, 17:01:02
Najlepsze, że VS, którego używam jako IDE poprawnie łapie funkcję z double. Sprawę rozwiąże pewnie using namespace std;
Używanie using namespace std; to proszenie się o kłopoty. Dodawaj wszędzie std:: i problem z głowy, a  czytelność kodu większa. Jeśli chodzi o IDE to lepiej jednak byłoby używać coś, co jest wieloplatformowe, czyli np. CodeBlocks, albo notatnik, a nie microsoftowy VS, który pewnie ma tam jakieś swoje dodatki działające wyłącznie pod windowsem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 30 Grudnia 2016, 17:18:59
Ale MaSzyna nie jest wieloplatformowa. Mogłaby być, jak ktoś cały kod przepisze np do C#.
Na razie zależy od DirectX i Win32API.
W przyszłości widziałbym cały kod w C# + Unity, wtedy byłoby wieloplatformowe.
Nie ma lepszego IDE od VS, ale jest lżejsze wieloplatformowe Visual Studio Code. Tyle, że jest sens go używać jak kod jest wieloplatformowy. Do kodu natywnego najlepiej używać narzędzia specjalizowanego. VS CE jest darmowe, więc każdy może sobie pobrać i zainstalować, najnowsza wersja ma też opcję minimalną (bez wszystkich krowiastych ficzerów).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 30 Grudnia 2016, 17:26:53
@HTD, @Surgeon to wie, rozpoczął 14 rok pobytu na tym forum. Jest od początku.
Ja nie widzę potrzeby, aby Maszyna była wieloplatformowa. A skoro już zacząłem, to coraz mniej widzę potrzebę multi playera co do tej pory wydawało się niezbędne.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 30 Grudnia 2016, 18:31:46
Jeśli chodzi o IDE to lepiej jednak byłoby używać coś, co jest wieloplatformowe, czyli np. CodeBlocks, albo notatnik, a nie microsoftowy VS, który pewnie ma tam jakieś swoje dodatki działające wyłącznie pod windowsem.
IDE to tylko IDE; nie ma raczej wplywu na kod, a pisanie czegokolwiek przy uzyciu notatnika to bezsensowny masochizm, ktory tylko stwarza pole dla trywialnych bledow. Of tego jest glupi komputer, zeby pamietal definicje klas i funkcji, i pilnowal czy skladnia sie zgadza.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 30 Grudnia 2016, 19:13:02
A skoro już zacząłem, to coraz mniej widzę potrzebę multi playera co do tej pory wydawało się niezbędne.

Wpierw trzeba opanować samą w sobie symulację, a fajerwerki zostawić na potem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 30 Grudnia 2016, 19:39:02
Przecież nikomu nie bronię pisać w notatniku. VS potrafi pisać kod multiplatformowy jeśli pamiętasz o tym, że chcesz to robić i nie używasz MFC, czy rzeczy z Visual C++ albo WinAPI albo DirectX.
Od razu też powiem, że problem nie leżał w użyciu std::abs() czy using namespace. Obie metody nie działają, gdyż wygląda, że Borland nie ma w STL zaimplemetowanego abs dla czego innego niż int. Na szybko dodałem dwie implementacje w mctools i działa ok.
Inna rzecz, że hamulce nie działają po podłączeniu wagonów. Teraz szukam, dlaczego ucieka powietrze z przewodu głównego.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Cesky Kretek w 31 Grudnia 2016, 11:39:37
W stosunku do średniej wytrwałości twórców tras to narazie to słomiany ogień.
Ale za to da nam to ogromny postęp i otworzy nowe możliwości.
Prowadzisz jakieś statystyki ile Ci jeszcze pozostało kodu do przepisania? Jakieś status-bary itp.? Tak z czystej ciekawości. :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 31 Grudnia 2016, 12:58:38
Z kodu do przepisania stricte pozostało już tylko wczytywanie za pomocą pascalowego parsera, co da się zmienić już teraz niezależnie od moich prac. Z tego co ja robię to teraz są poprawki błędów konwersji. Całość jest już na c++.
Jak na teraz to odkryłem, że mi ktoś włączył hamulec awaryjny w wagonach.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: El Mecánico w 01 Stycznia 2017, 14:39:30
Jak na teraz to odkryłem, że mi ktoś włączył hamulec awaryjny w wagonach.
Proponuję sprawdzić, czy aby ta zmienna/flaga jest inicjalizowana do właściwej wartości. Jeśli nie, trzeba prześledzić ścieżkę od parsera. Jeśli tak, to trzeba sprawdzić, czy od inicjalizacji do startu symulacji coś jej nie nadpisuje.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 02 Stycznia 2017, 07:02:33
Już myślałem, że sprawdziłem wszystkie zmienne w konstruktorze, ale nie. Ciągle są braki. Cóż, wagon nie dość, że miał zaciągnięty hamulec to i uszkodzony silnik ;) Teraz jeszcze raz po kolei sprawdzam każdą zmienną jaka jest zadeklarowana w moverze czy jest inicjowana w konstruktorze. Jestem tak pi razy drzwi w 1/4. Może do końca tygodnia wszystko sprawdzę i wtedy kolejny test.

  Dodano: [time]03 Stycznia 2017, 21:00:10[/time]
Zainicjowałem wszystko co brakowało. Dalej coś nie halo, ale już mniej. Z przewodu ma ubywać, ale teraz jest za szybko. Coś tam dalej źle się liczy. Mam lekko dość tej zabawy.

  Dodano: 03 Stycznia 2017, 22:55:29
Wstępnie obstawiam błędy w Oerlikonie wagonowym. Z pierwszych odkryć to nie działa mi typeid(T) i chciałbym się dowiedzieć dlaczego.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 04 Stycznia 2017, 01:43:03
Z pierwszych odkryć to nie działa mi typeid(T) i chciałbym się dowiedzieć dlaczego.
Sprawdz, czy wlaczona jest generacja danych RTTI w ustawieniach kompilatora. Ale takie rzeczy to powinno sie raczej robic przez wirtualna funkcje w klasie bazowej, ktora konkretne warianty juz sobie implementuja tak, jak im to pasuje. Reczne sprawdzanie typow i wywolywanie odzielnych funkcji na tej podstawie to troche dokladanie sobie roboty i proszenie sie o klopot ;/

edit:
patrzac w kod, to najprawdopodobniej nie dziala bo porownujesz wskaznik do klasy z klasa, wiec tam rownosci nigdy nie bedzie. Czyli nie powinno byc
typeid( foopointer ) == typeid( bar )
ale
typeid( *foopointer ) == typeid( bar )
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 04 Stycznia 2017, 07:01:04
Ahh, ile jeszcze rzeczy do odkrycia w c++... ;) Czemu w innych językach to jest proste a tu nie może.

  Dodano: [time]04 Stycznia 2017, 07:54:53[/time]
Chyba się przesiądę na VS2017RC ze względu na tą funkcję:
Cytuj
Find All References (Shift+F12) now helps you get around easily, even in complex codebases. It provides advanced grouping, filtering, sorting, searching within results, and (for some languages) colorization, so you can get a clear understanding of your references. For C++, the new UI includes information about whether we are reading from or writing to a variable.

  Dodano: [time]05 Stycznia 2017, 09:47:22[/time]
Znalazłem błąd. Spowodowany moim gapostwem, gdyż to jest niedogodność konwersji, że czasem wrzuca słowa sterujące za komentarze i zamiast else if masz komentarz. Zawsze przeglądam pliki po konwersji, żeby to znaleźć, a w tym przypadku mi umknęło. Teraz powietrze nie ucieka już. Późno było to już nie robiłem znaczących testów. Dzisiaj odhamowanie składu i ruszenie. Jeśli się uda ruszyć ;)

  Dodano: [time]05 Stycznia 2017, 23:35:14[/time]
No znalazłem więcej błędów. Jeden z nich to była błędna konwersja typu wkładki hamulca, i wszystko miało te same wkładki żeliwne ;) Było też parę innych błędów, ale ciągle wagon jest nieodhamowywalny. Bo ostatniej poprawce zrobiłem nową dziurę i teraz ciśnienie w przewodzie mam -1 ;)

  Dodano: [time]06 Stycznia 2017, 21:02:47[/time]
Przewód załatany. Brak dopisania funkcji jako wirtualnej w klasie polimorficznej. Nadal źle liczy ciśnienie w hamulcu.

  Dodano: 06 Stycznia 2017, 23:58:48
No powiem, że ostatni błąd był najgłupszym jaki widziałem do tej pory. Otóż
if ((BrakeStatus & b_on == b_on)) nie jest tożsame z if ((BrakeStatus & b_on) == b_on) Nie wiem czemu tak to działa ale po zmianie na poprawną wersję hamulce działają jak potrzeba.
Elektrykiem da się ruszyć, ale reaguje tylko na pierwszą pozycję i nie zwiększa prądu wraz z wejściem na kolejne.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 07 Stycznia 2017, 01:46:11
Nie wiem czemu tak to działa ale po zmianie na poprawną wersję hamulce działają jak potrzeba.
Bo taka jest typowa kolejnosc operacji w c++ ( http://en.cppreference.com/w/cpp/language/operator_precedence )

kombinacje bitowe i logiczne (#10-14) sa z reguly wykonywane po porownaniach (#8-9) czyli ta pierwsza wersja to w praktyce
if( BrakeStatus & 1 )
bo b_on == b_on bedzie zawsze prawdziwe.

porownanie to operator jak kazdy inny, a c++ te rzeczy sa w zasadzie defniowane luzno, jesli w ogole, dlatego prawie zawsze warto dla pewnosci wymuszac kolejnosc nawiasami itp, inaczej ugryzie cie to nie wiadomo kiedy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 07 Stycznia 2017, 16:17:31
W każdym razie w jednych if-aach było poprawnie a w innych nie.
Z dzisiejszych testów wynika, że czuwak nie działa, znaczy włącza się, ale nie hamuje ;)
Teraz sprawdzam czemu źle liczy prąd w obwodzie.

  Dodano: [time]07 Stycznia 2017, 16:50:31[/time]
Uwielbiam C++. Do tej pory nie mogę zrozumieć co przyświecało twórcom kompilatorów, że jeśli wynik jest typu double, a pierwsza liczba wymnażana po prawej jest typu int to policzy całość mnożenia w liczbach całkowitych i wynik zrzutuje na double.

  Dodano: 07 Stycznia 2017, 16:58:50
Ahh, zapomniałem dodać, że kiedy wrzucam pozycje na czysto to nie przeskakuje zmienna, ale jeśli na funkcji obsługującej klawisze wrzucę breakpointa to ją przerzuca.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 07 Stycznia 2017, 17:50:15
Uwielbiam C++. Do tej pory nie mogę zrozumieć co przyświecało twórcom kompilatorów, że jeśli wynik jest typu double, a pierwsza liczba wymnażana po prawej jest typu int to policzy całość mnożenia w liczbach całkowitych i wynik zrzutuje na double.
A to akurat dziwne. Standardowo jest w druga strone (https://msdn.microsoft.com/en-us/library/aetzh118.aspx) tzn jesli jest np float = int * float to kompilator promuje int do float i wszystko dziala: 1 * 1.5 = 1.5  Chociaz i tak dla pewnosci warto stosowac static_cast itp, ale to chyba cos z Borlandem, a nie c++ jako takim.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: ryba825 w 07 Stycznia 2017, 19:48:06
Uwielbiam C++. Do tej pory nie mogę zrozumieć co przyświecało twórcom kompilatorów, że jeśli wynik jest typu double, a pierwsza liczba wymnażana po prawej jest typu int to policzy całość mnożenia w liczbach całkowitych i wynik zrzutuje na double.
A to akurat byłoby bardzo dziwnie, bo to nie ma żadnego sensu. Może bug kompilatora?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 08 Stycznia 2017, 18:00:29
To musi być Borland, bo w jego przypadku double x = 3/2 => 1, a 3.0/2 => 1.5. Więc wczoraj wieczorem przeglądałem cały mover, żeby wychwycić te wszystkie miejsca gdzie liczy na całkowitych.

  Dodano: 08 Stycznia 2017, 18:25:41
Da się normalnie jeździć, tylko nie działa czuwak. Szukam przyczyny czuwaka. Chciałbym jeszcze też zrobić parę testów zanim puszczę do was, żeby nie było strasznego crapa.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 08 Stycznia 2017, 18:57:08
To musi być Borland, bo w jego przypadku double x = 3/2 => 1, a 3.0/2 => 1.5. Więc wczoraj wieczorem przeglądałem cały mover, żeby wychwycić te wszystkie miejsca gdzie liczy na całkowitych.
A nie, 3/2 = 1 to akurat "normalne" -- konwersja z liczb calkowitych na zmiennoprzecinkowe ma miejsce, jesli przynajmniej jeden ze skladnikow operacji matematycznej jest typu float albo double. Jesli oba sa typu int, to kompilator tak je zostawi. Przypisanie wyniku do zmiennej nastepuje juz po fakcie, jako odrebna operacja, wiec nie wplywa na to jak przeprowadzana jest sama matematyka; o tym decyduja tylko typy skladnikow.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 08 Stycznia 2017, 20:00:42
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).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 10 Stycznia 2017, 07:46:38
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
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 10 Stycznia 2017, 08:02:02
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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 10 Stycznia 2017, 19:47:47
Nie wiem, czy ma to zwiazek, ale zwroc uwage na ComputeCollision()
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 :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 10 Stycznia 2017, 20:47:10
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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 10 Stycznia 2017, 21:05:32
Co on tam tak liczy, ze mu sie w double albo long nie miesci? o.O
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 11 Stycznia 2017, 07:51:14
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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 11 Stycznia 2017, 09:54:20
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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: szczawik w 11 Stycznia 2017, 10:07:18
@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ę.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Mariusz1970 w 11 Stycznia 2017, 10:34:44
Coś jest na rzeczy, o czym pisze HTD, jednak przypomina mi to to:
t=05m00s
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 11 Stycznia 2017, 13:28:49
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?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 11 Stycznia 2017, 13:44:39
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#.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 11 Stycznia 2017, 13:56:48
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 ;)

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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 11 Stycznia 2017, 14:48:47
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 ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 11 Stycznia 2017, 15:22:39
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
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
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 12 Stycznia 2017, 07:48:18
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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 12 Stycznia 2017, 16:49:08
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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 12 Stycznia 2017, 19:40:37
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ł.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 13 Stycznia 2017, 07:08:00
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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 13 Stycznia 2017, 09:52:37
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)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 13 Stycznia 2017, 11:00:47
Ł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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 13 Stycznia 2017, 17:45:01
Ł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 :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 13 Stycznia 2017, 18:58:10
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 ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: szogun w 13 Stycznia 2017, 20:09:21
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 ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: matek123 w 13 Stycznia 2017, 20:32:44
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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 13 Stycznia 2017, 20:35:12
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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 14 Stycznia 2017, 07:16:55
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?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: El Mecánico w 14 Stycznia 2017, 12:31:02
Nie da się tego zestawu else-if'ów przerobić na switch-case?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 14 Stycznia 2017, 17:07:49
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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: El Mecánico w 14 Stycznia 2017, 18:48:55
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?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 14 Stycznia 2017, 19:31:41
Nie zrozumielismy sie :)

https://github.com/firleju/maszyna/blob/mover_in_c%2B%2B/Train.cpp

zerknij do InitializeCab()
(..)
            else if (str == AnsiString("mainctrlact:")) // zabek pozycji aktualnej
                ggMainCtrlAct.Load(Parser, DynamicObject->mdKabina);
            else if (str == AnsiString("scndctrl:")) // bocznik
                ggScndCtrl.Load(Parser, DynamicObject->mdKabina);
            else if (str == AnsiString("dirkey:")) // klucz kierunku
                ggDirKey.Load(Parser, DynamicObject->mdKabina);
(..)
i tak jeszcze ze 100 razy. Tego sie nie da za bardzo wprost przerobic na switch() bo switch musi miec stale wartosci (czyli int albo enum, tak jak mowisz) i nie lyka w takiej sytuacji wyszukiwania przypadku wg stringa. Tzn mozna by sie pewnie bawic z jakas tabela konwersji string->enum i zrobic switch() dla tych konwertowanych wartosci, ale to jest troche pisania bez gwarancji, ze i tak nie wyskoczy mu ten sam limit. To w takiej sytuacji wole to na razie zostawic, a przerobic mozna potem raz a porzadnie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 15 Stycznia 2017, 05:50:11
Nawet nie probowalem uruchamiac, bo to nie ma prawa dzialac (ponad tysiac ostrzezen roznej masci) niemniej (maly) krok naprzod jest ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: przepioramarcin w 15 Stycznia 2017, 08:03:02
TD, EU07 - Od strony elektryki wszystko wydaje się OK. Problem z hamulcem pomocniczym - działa dopiero na ostatniej pozycji hamowania. Nie działa odluźniacz. Hamulec zasadniczy OK.
Faktycznie trochę bardziej buja :).
TD, SU45 - nie udało się ruszyć. Po uruchomieniu silnika gdy załączymy sprężarkę słychać ponowny rozruch silnika. Ciśnienie w zbiorniku głównym stoi na zerze.
TD, EN57 - chyba wszystko w porządku. Nawet nie rzuca mechanikiem tak jak w EU07.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 15 Stycznia 2017, 14:31:40
"I'm making a note here:
 Huge success!"


Az sie zdziwilem, bo szybciej sie to wszystko uruchomilo niz myslalem. Milion rzeczy tam jest jeszcze do poprawienia na 100 procent, ale w kazdym razie gra, jezdzi i buczy.

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 16 Stycznia 2017, 10:33:40
Jako, że masz te same błędy co ja, to z tym jeździ bym nie przesadzał ;)
Ale chętnie przyjmę poprawki, żeby już też się pozbyć BCB. Nadal nie umiem w solucji zrobić takich ładnych folderów z plikami i mam wszystko płaskie :(
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 16 Stycznia 2017, 14:44:30
No nie calkiem te same, pare poprawilem ;)
musze jeszcze zintegrowac z poprawkami ktore zrobiles w miedzyczasie, ale wersja tymczasowa jest tutaj: https://github.com/tmj-fstate/maszyna/tree/parser_replacement

a co do folderow w visual studio, kliknij prawym przyciskiem na projekcie albo folderze w okienku solution, i Add->New Filter. Mozesz wtedy wrzucac do nich pliki przez drag&drop.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: El Mecánico w 16 Stycznia 2017, 15:00:00
[ciach] i tak jeszcze ze 100 razy. [/ciach]
Czyli kwestia tego, że mamy bardzo dużo słów kluczowych definiujących elementy taboru. Wiem, naleciałość z czasów, kiedy jedynym dostępnym edytorem do MaSzyny był zwykły edytor tekstu. A próbował ktoś kompilatora GNU? Może to ograniczenie dotyczy tylko kompilatora ze stajni M$?

[luźna_dywagacja]
A tak docelowo, to chyba trzeba będzie trochę wcześniej niż później przejść na jakiś (pre)kompilowany format zapisu danych konfiguracyjnych i odejście od postaci tekstowych.
[/luźna_dywagacja]
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 16 Stycznia 2017, 15:36:25
Czyli kwestia tego, że mamy bardzo dużo słów kluczowych definiujących elementy taboru. Wiem, naleciałość z czasów, kiedy jedynym dostępnym edytorem do MaSzyny był zwykły edytor tekstu. A próbował ktoś kompilatora GNU? Może to ograniczenie dotyczy tylko kompilatora ze stajni M$?
Inne kompilatory powinny sobie poradzic, standardowo limit to 256 tego typu blokow. Tak czy owak nie ma to juz znaczenia, rozbilem funkcje na pare blokow i chodzi, a w przyszlosci mozna to w ogole zautomatyzowac, np budujac w locie tabele elementow z otrzymanych typow/nazw, zamiast kodowania na sztywno.

@firleju merge zrobiony, podrzucilem pull request. Mozesz ciagnac kiedy ci pasuje :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 16 Stycznia 2017, 16:05:16
Aha, z zauwazalnych bledow -- cos jest na rzeczy z kolami/wozkami (moze innymi sub-modelami tez, nie przygladalem sie) W wagonach i samochodach przednie kola znikaja gdzies jak tylko pojazd zaczyna sie ruszac. W lokomotywach chyba jest w porzadku. Tak samo jest w tym skompilowanym .exe umieszczonym wczesniej w watku, czyli to nie moja wina ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 16 Stycznia 2017, 21:30:51
Ja i tak jestem szczęśliwy, że nie będę miał już dwóch środowisk do pracy. BCB mnie już doprowadzał do szału topornością. No, ale jak się nie dziwię, jak popatrzę na VS6 to obsługa wygląda podobnie, czyli raczej taki był standard tamtych czasów.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: queuedEU w 16 Stycznia 2017, 21:44:44
Nadal nie wierzę :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 16 Stycznia 2017, 21:47:46
Cytat: Yoda
I dlatego ci się nie udaje.
:)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: queuedEU w 16 Stycznia 2017, 21:52:59
Jak tak patrze w ten mover.cpp to tam wiekszosc jest tak jak bylo po moim tlumaczeniu, szkoda ze Firlej nie podkreslil bledow, teraz nie ma dowodow ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: queuedEU w 16 Stycznia 2017, 21:54:39
Cesky, szykuj browary czy co tam mialo byc,  bo w tym przypadku opoznienie sie nie liczy :).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 16 Stycznia 2017, 21:59:19
Q, całą historię znajdziesz na githubie ;) Więc wszystko jest publiczne :D Zresztą ciężko popełniać błędy w czymś czego nie ma :DDDD
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 16 Stycznia 2017, 23:03:38
Aha, cppcheck znalazl takie cos w mover.cpp
            if ((TrainType != dt_ET22) ||
                ((TrainType == dt_ET22) &&
                 (ScndCtrlPos ==
                  0))) // w ET22 nie da si&ecirc; kr&ecirc;ci&aelig; nastawnikiem przy w&sup3;&sup1;czonym boczniku

Redundant condition: TrainType==dt_ET22. 'TrainType!=dt_ET22 || (TrainType==dt_ET22 && ScndCtrlPos==0)' is equivalent to 'TrainType!=dt_ET22 || ScndCtrlPos==0'
czyli warunek bedzie spelniony zawsze, gdy ScndCTrlPos = 0 albo gdy pociag nie jest typu ET22. Sadzac po komentarzu to nie jest dokladnie to, co autor mial na mysli, ale nie wiem co dokladnie autor mial na mysli, wiec wolalem nie ruszac... ale to prawdopodobnie przyczyna dlaczego sterowanie nie jest calkiem takie, jak powinno byc.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 17 Stycznia 2017, 00:04:02
W pascalu nie ma tu żadnych niejasności.
if (TrainType<>dt_ET22) or ((TrainType=dt_ET22) and (ScndCtrlPos=0)) then //w ET22 nie da się kręcić nastawnikiem przy włączonym boczniku
Kontrola nastawnika jest, jeśli pojazd nie jest et22 lub jest et22 z bocznikiem na pozycji 0.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: ryba825 w 17 Stycznia 2017, 00:14:41
Stele, skoro TrainType<>dt_ET22 jest fałszem to TrainType=dt_ET22 jest prawdą, więc skraca się do if TrainType<>dt_ET22 or ScndCtrlPos=0
Coś pominąłem?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 17 Stycznia 2017, 00:38:40
No TrainType=dt_ET22 and ScndCtrlPos<>0 dla którego ma być fałsz. Patrząc na nawiasy, to matematycznie powinno działać. A że cpp potrafi traktować to nieco inaczej, to już Grześ się przekonał wyżej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: ryba825 w 17 Stycznia 2017, 01:01:29
Żeby wzięło pod uwagę drugi warunek, to TrainType musi być dt_ET22, więc nie ma sensu sprawdzać tego drugi raz. Jeśli TrainType nie nie jest dt_ET22, to jest dt_ET22, więc tylko zerowość ScndCtrlPos jest brana pod uwagę. No chyba że w Pascalu porównanie i różność działają inaczej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 17 Stycznia 2017, 01:12:25
Istotnie, macie rację.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 17 Stycznia 2017, 01:37:20
Kontrola nastawnika jest, jeśli pojazd nie jest et22 lub jest et22 z bocznikiem na pozycji 0.
Czyli ujmujac to inaczej, jesli pociag to ET22 z bocznikiem na pozycji innej niz neutralna, to kontroli nie ma? Zmienilem zapis na
if( false == (( TrainType == dt_ET22 ) && ( ScndCtrlPos != 0 )) ) {
...
}
wychodzi na to samo, ale z malym rozumkiem troche latwiej to ogarnac :)

edit: a jak sie zastanowic, to mozna z tego wyrzucic negacje i po prostu od razu zwracac false, zamiast sie bawic w zagniezdzanie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 17 Stycznia 2017, 07:22:24
tmj, możesz też podrzucić solucję. Chcę mieć pewność, że czegoś nie zwaliłem podczas już lat pracy na dwóch środowiskach i 3 różnych wersjach VS. Jakąś zresztą będzie trzeba wrzucić na git-a.
Odnosząc się do warunku to chyba łatwiej będzie zapisać
if (TrainType != dt_ET22 || ScndCtrlPos == 0)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: surgeon w 17 Stycznia 2017, 17:02:55
Aha, cppcheck znalazl takie cos w mover.cpp
            if ((TrainType != dt_ET22) ||
                ((TrainType == dt_ET22) &&
                 (ScndCtrlPos ==
                  0))) // w ET22 nie da si&ecirc; kr&ecirc;ci&aelig; nastawnikiem przy w&sup3;&sup1;czonym boczniku

Redundant condition: TrainType==dt_ET22. 'TrainType!=dt_ET22 || (TrainType==dt_ET22 && ScndCtrlPos==0)' is equivalent to 'TrainType!=dt_ET22 || ScndCtrlPos==0'
czyli warunek bedzie spelniony zawsze, gdy ScndCTrlPos = 0 albo gdy pociag nie jest typu ET22. Sadzac po komentarzu to nie jest dokladnie to, co autor mial na mysli, ale nie wiem co dokladnie autor mial na mysli, wiec wolalem nie ruszac... ale to prawdopodobnie przyczyna dlaczego sterowanie nie jest calkiem takie, jak powinno byc.
Moim zdaniem wskazany fragment pascala został przetłumaczony prawidłowo. Po prostu można to skrócić do tego co zaproponował cppcheck i nadal będzie to działało tak samo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 17 Stycznia 2017, 18:21:29
tmj, możesz też podrzucić solucję. Chcę mieć pewność, że czegoś nie zwaliłem podczas już lat pracy na dwóch środowiskach i 3 różnych wersjach VS. Jakąś zresztą będzie trzeba wrzucić na git-a.
Dolaczam ta, ktorej uzywam, chociaz pewnie trzeba bedzie poprawic sciezke (skonfigurowany jest zeby ciagnac dsound.lib z instalacji directX SDK)

Uporzadkowalem troche IncMainCtrl() dla latwiejszego czytania, i bylbym wdzieczny gdyby ktos rzucil okiem, czy tam jest wszystko w porzadku pod wzgledem logiki, bo ja sie na pociagach az tak nie znam :)  zwlaszcza sekcja ElectricSeriesMotors:

// basic fail conditions:
if( ( CabNo == 0 )
|| ( MainCtrlPosNo <= 0 ) ) {
// nie ma sterowania
return false;
}
if( ( TrainType == dt_ET22 ) && ( ScndCtrlPos != 0 ) ) {
// w ET22 nie da si&ecirc; kr&ecirc;ci&aelig; nastawnikiem przy w&sup3;&sup1;czonym boczniku
return false;
}
if( ( TrainType == dt_EZT ) && ( ActiveDir == 0 ) ) {
// w EZT nie da si&ecirc; za&sup3;&sup1;czy&aelig; pozycji bez ustawienia kierunku
return false;
}

bool OK = false;
    if (MainCtrlPos < MainCtrlPosNo)
    {
switch( EngineType ) {
case None:
case Dumb:
case DieselElectric:
case ElectricInductionMotor:
{
if( CtrlSpeed > 1 ) {
OK = ( IncMainCtrl( 1 )
&& IncMainCtrl( CtrlSpeed - 1 ) ); // a fail will propagate up the recursion chain. should this be || instead?
}
else {
++MainCtrlPos;
OK = true;
}
break;
}

case ElectricSeriesMotor:
{
if( ActiveDir == 0 ) { return false; }

if( CtrlSpeed > 1 ) {
// szybkie przejœcie na bezoporow&sup1;
if( TrainType == dt_ET40 ) {
break; // this means ET40 won't react at all to fast acceleration command. should it issue just IncMainCtrl(1) instead?
}
while( ( RList[ MainCtrlPos ].R > 0.0 )
&& IncMainCtrl( 1 ) ) {
// all work is done in the loop header
;
}
// OK:=true ; {takie chamskie, potem poprawie} <-Ra: kto mia&sup3; to
// poprawi&aelig; i po co?
if( ActiveDir == -1 ) {
while( ( RList[ MainCtrlPos ].Bn > 1 )
&& IncMainCtrl( 1 ) ) {
--MainCtrlPos;
}
}
OK = false; // shouldn't this be part of the loop above?
}
else { // CtrlSpeed == 1
++MainCtrlPos;
OK = true;
if( Imax == ImaxHi ) {
if( RList[ MainCtrlPos ].Bn > 1 ) {
if( true == MaxCurrentSwitch( false )) {
// wylaczanie wysokiego rozruchu
SetFlag( SoundFlag, sound_relay );
}
if( TrainType == dt_ET42 ) {
--MainCtrlPos;
OK = false;
}
}
}
if( ActiveDir == -1 ) {
if( ( TrainType != dt_PseudoDiesel )
&& ( RList[ MainCtrlPos ].Bn > 1 ) ) {
// blokada wejœcia na równoleg&sup3;&sup1; podczas jazdy do ty&sup3;u
--MainCtrlPos;
OK = false;
}
}
}

if( ( TrainType == dt_ET42 ) && ( true == DynamicBrakeFlag ) ) {
if( MainCtrlPos > 20 ) {
MainCtrlPos = 20;
OK = false;
}
}
// return OK;
break;
}

case DieselEngine:
{
if( CtrlSpeed > 1 ) {
while( MainCtrlPos < MainCtrlPosNo ) {
IncMainCtrl( 1 );
}
}
else {
++MainCtrlPos;
if( MainCtrlPos > 0 ) { CompressorAllow = true; }
else                  { CompressorAllow = false; }
}
OK = true;
break;
}

case WheelsDriven:
{
OK = AddPulseForce( CtrlSpeed );
break;
}
} // switch EngineType of
    }
    else {// MainCtrlPos>=MainCtrlPosNo
if( true == CoupledCtrl ) {
// wspólny wa&sup3; nastawnika jazdy i bocznikowania
if( ScndCtrlPos < ScndCtrlPosNo ) { // 3<3 -> false
++ScndCtrlPos;
OK = true;
}
else {
OK = false;
}
}
    }
konkretnie to kawalek if( ActiveDir == -1 ) bo tam jednoczesnie zwieksza ciag o 1 uzywajac wywolanie IncMainCtrl(1) i zaraz w tej samej petli zmniejsza o 1, co wydaje sie troche bez sensu..? Aha, i jeszcze to, ze blok dla CtrSpeed > 1 zawsze zwraca false. Nie powinno to byc ograniczone tylko to pod-bloku ActiveDir == -1, tak jak w pozostalych miejscach?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 17 Stycznia 2017, 21:36:03
Na mojej wersji mam 44 errory, najczęściej związane z char* niezgodny z LPCWSTR. Ściągam repo tmj i zobaczę na nim czy czegoś nie zwaliłem razem z łączeniem.

EDIT:
Nie chce mi się bawić. Nadgrywam na moje repo solucję tmj, bo tak będzie szybciej i prościej niż szukanie różnic w ustawieniach.

EDIT2:
Ranna sesja zakończona pomyślnym zbudowaniem. Niestety brakuje jakiejś dll-ki. Gdzie są wpisane .lib których używa przy budowaniu?

EDIT3:
Już wiem co się stało z dll-k - mam jakiś błąd instalacji VS i muszę przeinstalować jeden komponent. Lib-y już też znalazłem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 18 Stycznia 2017, 08:04:54
Jesli brakuje .dll to najprawdopodobniej glew32.dll, ze strony glew ( http://glew.sourceforge.net/ )  poprzednio bylo to chyba laczone statycznie, i domyslnie brakuje jej w paczce z maszyna.

Wrzucilem na githuba male uaktualnienie -- glownie poprawiona wiekszosc memory leaks, przy okazji poczyscilem troche komponenty do hamulcow itp, wylazlo tam kilka wiecej nieinicjalizowanych zmiennych ;)  teraz beda chyba wszystkie, moze poprawi to troche niektore ze zgloszonych bledow, a moze nie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 18 Stycznia 2017, 08:44:40
Glew już ściągnąłem, gdyż nie budował ;) Teraz lib jest także na repo.
Ja bym Cię prosił, żeby jednak używać CamelBack do nazw funkcji.

EDIT:
Ta dll-ka to jest komponent vsredist, a dokładnie ucrtbased.dll.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 18 Stycznia 2017, 19:49:37
Podlaczylem z powrotem otwieranie drzwi, choc na razie jest po chamsku zakodowane na sztywno dla skladow EZT
Docelowo powinien to byc zapewne wpic w .mmd albo coos, z tym ze w takiej sytuacji powinno to nastapic przed ladowanie glownego pudla, zeby kod byl w stanie podczepic prawidlowa wersje funkcji animujacej.

edit: znalazlem przyczyne znikajacych niektorych osi -- kod ladujacy pliki .fiz potrafil ustawic srednice na 0.0 (kiedy parameter nie byl podany) i przepuszczal to, bo mial zle ustawiony warunek brzegowy. W rezultacie przy kalkulacji obrotow bylo dzielenie przez 0. Teraz powinno byc dobrze, ale moze warto zmienic funkcje getkeyval() na cos w stylu bool getkeyval( _Type &Parameter, std::string const &Key) wtedy bedzie mogla automatycznie uaktualnic docelowa zmienna, a jak nie znajdzie wartosci to zwroci false. I przy okazji odpadnie koniecznosc recznego definiowania typow.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 19 Stycznia 2017, 07:07:34
getkeyval to wytwór Q. Najlepiej by było chyba zrobić wersję z parametrem domyślnym w przypadku nie znalezienia słowa kluczowego.
Coś zepsułeś w hamulcach, gdyż po narzuceniu twoich zmian z pull-a znowu nie ma ciśnienia w cylindrach hamulcowych po starcie TD a powinno być. Mnie już naprawdę nie chce się tego szukać n-ty raz. Hamulce działają na wersji c3 i tak powinno zostać.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: El Mecánico w 19 Stycznia 2017, 13:35:31
Dobrze by było, aby każda krytyczna zmienna miała domyślną wartość początkową ustawioną na jakąś bezpieczną wartość...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 19 Stycznia 2017, 17:12:31
Coś zepsułeś w hamulcach, gdyż po narzuceniu twoich zmian z pull-a znowu nie ma ciśnienia w cylindrach hamulcowych po starcie TD a powinno być. Mnie już naprawdę nie chce się tego szukać n-ty raz. Hamulce działają na wersji c3 i tak powinno zostać.
Masz na mysli to, co jest wlaczone do twojej wersji, czy to co dodalem u siebie ostatnio? Jesli to pierwsze to nie wiem czy to moja wina, bo akurat hamulcow w tej wersji patcha nie dotykalem :) (dodalem mu tam #pragma once i tyle) Natomiast w niektorych hamulcach bylo wtedy jeszcze pare niezainicjalizowanych zmiennych, wiec byc moze to jest przyczyna tego zachowania. To jest poprawione w uaktualnieniu ktore wrzucilem pozniej, tutaj na 99% inicjalizuje wszystkie zmienne tak, jak by to robil Borland, wiec powinno pomoc, a nie zaszkodzic (chociaz moze tez pomoc w uaktywnieniu bledow ktore sa gdzie indziej, a do tej pory byly maskowane przez brak inicjalizacji)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 19 Stycznia 2017, 17:38:03
My fault. Nie zauważyłem, że nadałem prędkość i dawał wartości jak dla odjazdu a nie zatrzymania. Tak właśnie jest jak się robi parę rzeczy na raz.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 19 Stycznia 2017, 18:12:24
Wersja release. Może zawierać poprzednie błędy. Na repo wszystkie rzeczy potrzebne do budowania na VS2013 lub VS2015. Może nie działać na WinXP, ale powinno. W załączniku także potrzebny dll do Glew wersji 2.0.
Tmj, niestety nowy pull nie pójdzie łatwo. Są konflikty.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 19 Stycznia 2017, 18:16:53
Ah ok, bo juz sie przestraszylem. Przy okazji pchnalem dotychczasowe poprawki, ale troche sie spoznilem, bedziesz musial porownac czy tam cos sie nie wcina :) (teoretycznie nie powinno, ale teoria sobie itp)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 19 Stycznia 2017, 18:21:55
Tak czy siak jak zaciągniesz zmiany to będzie trzeba poprawić, a w tym co zrobiłeś to chyba się lepiej orientujesz. Z pierwszego rzutu oka to nie wiem po co usuwasz inicjację zmiennych w hamulcach.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 19 Stycznia 2017, 18:27:27
Tak czy siak jak zaciągniesz zmiany to będzie trzeba poprawić, a w tym co zrobiłeś to chyba się lepiej orientujesz. Z pierwszego rzutu oka to nie wiem po co usuwasz inicjację zmiennych w hamulcach.
Inicjacja jest teraz wpisana bezposrednio w definicji zmiennych w naglowku, wiec to, co bylo w konstruktorze to tylko (wolniejszy) duplikat. Trudniej w ten sposob przeoczyc brak inicjalizacji.

Przegladam konflikty -- w driver.cpp mozesz dac moja wersje, to jest tylko minimalna kosmetyka przy komunikacie. Reszte podam jak sprawdze.
dynobj.cpp -- tak samo, mozesz dac moj kod. podejrzewam ze diff w wiekszosci glupieje bo w komentarzach sa pozostalosci po polskich znakach i on nie bardzo wie jak to lyknac.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 19 Stycznia 2017, 18:33:02
No tak. Przeglądając nie zauważyłem. W klasach hamulców wystarczy unique_ptr. Tam nie ma żadnego dzielenia się wskaźnikami. Szczególnie w przypadku czegokolwiek na TReservoir.
Nie ma sensu poprawiania komentarzy. Używam clang_format i to leci automatem. Tak samo odległości pomiędzy znakami itd.

Właśnie nie wiem co z tymi byłymi polskimi znakami. Na jakimś etapie w niektórych plikach źle zostały skonwertowane.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 19 Stycznia 2017, 18:42:20
No ja nie wiedzialem czy tam we flakach nie ma jakiegos przekazywania parametrow, wiec dla pewnosci dalem shared. Jak sie to wszystko wyprostuje to mozna poprawic, na razie nie szkodzi specjalnie, ze jest.

Komentarzy w wiekszosci nie tykalem, posklejalem tylko niektore linie
ktore
wygladaly
tak,
zeby to prosciej bylo ogarnac ;) polskie znaki moze w ogole wyrzucic z komentarzy? prawdopodobnie glupieje, bo u mnie jest angielski win 10, a pliki nie sa chyba zapisane w Unicode wiec to sie zmienia w te i we w te.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 19 Stycznia 2017, 18:45:17
train.cpp jest bardziej skomplikowany, tak pol na pol twoich poprawek, i moich. najlepiej odwolam update, polacze to na spokojnie lokalnie u siebie, i pchne jeszcze raz.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 19 Stycznia 2017, 18:56:52
To zanim zaczniesz się bawić przeglądnę wszystkie pliki i spróbuję naprawić kodowanie. a potem konwersja na UTF-8.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 19 Stycznia 2017, 20:26:13
No juz za pozno, zaczalem sie bawic zanim przeczytalem :)  nowy pull request wyslany, powinno sie polaczyc. Lokalnie kompiluje sie i dziala, chociaz czy cos sie nie zchrzanilo wyjdzie dopiero w praniu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: ryba825 w 19 Stycznia 2017, 20:45:16
Używacie jakichś linterów? Formatowanie kodu (wcięcia) wygląda jakby decydowała o tym funkcja "random". ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: ryba825 w 19 Stycznia 2017, 20:54:41
Mam na myśli takie coś. https://google.github.io/styleguide/cppguide.html#Spaces_vs._Tabs Czyli używanie 2 spacji zamiast tabulatora. Bardzo skraca zagnieżdżenia.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 19 Stycznia 2017, 21:09:54
formatowanie wyglada jak wyglada, bo kazdy robi tak, jak jest przyzwyczajony, a standardow jest tyle ile programistow + 1 ;)

2 spacje sa wg mnie raczej nieczytelne; przy wiekszym monitorze w niektorych ukladach zaczynasz sie zastanawiac czy to wciecie czy tylko cie oczy myla. A i zagniezdzen nie ma co za bardzo splaszczac -- jak ci zaczyna linia wychodzic za ekran z powodu zagniezdzen, to jest to niezly sygnalizator ze z kodem jest pewnie cos nie tak na bardziej ogolnym poziomie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: ryba825 w 19 Stycznia 2017, 21:19:30
Używam 2 spacji w Rubym i Javascripicie i nie mam problemu z czytelnością. ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 19 Stycznia 2017, 22:10:05
Ja tez bylem kiedys mlody i mialem dobre oczy. ;d
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: ryba825 w 19 Stycznia 2017, 22:18:42
To już od Was zależy. Ja tylko proponuję. ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 20 Stycznia 2017, 07:37:45
Ryba, każdy plik przeszedł tutaj wstępnie przez formater kodu. To potem są jaja bo nie po każdej zmianie się tego używa, a VS studiu domyślnie używa tabów zamiast spacji (co można zmienić w opcjach oczywiście). Ale wystarczy znowu przejechać formaterem i wszystkie tabulatory lecą na spacje z automatu. VS też ma dodatek do zainstalowania jak coś.
No widziałem, że zrobiłeś zmiany, a ja już w tym czasie zdążyłem zrobić 3 kolejne commity z ponad 60 plikami na zmienionym formacie. Teraz lecę te najgorsze, które trzeba nadgrywać z ostatniej dobrej wersji. Zobaczymy, czy będzie się chciało połączyć.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 20 Stycznia 2017, 08:47:03
A tak z innej beczki, no koozwa, ja nie moge -- czy czytanie negatywnych indeksow z tablicy, jak na zalaczonym screenie to jest by design, czy sie tylko przemknelo do tej pory niezauwazone, bo sobie kod po prostu lapal cos tam z poprzedniej zmiennej, a AttachPrev() lyka wszytko bez weryfikacji? o.O
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 20 Stycznia 2017, 08:52:31
Jak to jest w Ground to od początku jest w cpp. Więc by design, lub by błąd. ;) Nie wie nikt, ale uważaj jak zmieniasz, bo łatwo zepsuć, bardzo trudno naprawić. Możesz też chwilę poczekać ze zmianami aż ogarniemy kodowanie?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 20 Stycznia 2017, 09:10:11
No wlasnie boje sie ruszyc bo tam straszna sieczka jest, dlatego pytam :)  na razie nie bede grzebal wiecej, poczekam az skonczysz formatowanie itp, to tylko wyskoczylo przy okazji, jak probowalem ogarnac, czemu nie renderowal zadnych pojazdow na drogach. Wyszlo na to, ze w kodzie sporo jeszcze opiera sie na odczycie troche 'na slepo', a tryb debug specjalnie inicjalizuje pamiec smieciami, zeby to latwiej wylapac, wiec faktycznie zaczyna to wychodzic. No, ale samochody znowu jezdza, i nawet maja wszystkie cztery kolka ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 20 Stycznia 2017, 10:44:45
Jeśli dobrze pójdzie to dzisiaj skończę z formatowaniem.
Proponuję ustalić podział prac na najbliższy czas, żeby nie robić sobie konfliktów.
No i może najważniejsze w jaką stronę idziemy z modernizacją kodu.
Z mojej strony to najpierw rozwiązać błędy zgłoszone podczas pierwszych testów a potem rozdzielenie movera na klasy poszczególnych pojazdów a nie jeden worek do wszystkiego.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 20 Stycznia 2017, 16:10:49
Ja sie tam specjalnie wtracac nie bede ;) a propos rozwiazywania bledow, SU45 (i zapewne pokrewne, jesli sa) nie jezdzi, bo ma chyba podlaczony zly kod -- z tego co zauwazylem to probuje uzywac tablicy DList, ktora jest w jej przypadku pusta/wypelniona smieciami, natomiast odczytu zawartosci WWList z pliku .fiz nie ma jeszcze w kodzie. Ladowanie tablicy akurat moge dopisac, nie powinno sie z niczym pogryzc, ale podlaczanie kodu do jazdy, to juz musi sie tym zajac ktos ciezko doswiadczony.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 20 Stycznia 2017, 17:09:12
W takim razie nie jeżdżą spalinowe w ogóle. Do kodu podłączać nie trzeba. "Tylko" wczytać wszystkie parametry z pliku fiz. Do tego trzeba już porównywać kod pascalowy. Jeśli chcesz to ok, jeśli nie to zrobię to jak tylko skończę poprawiać polskie litery.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 20 Stycznia 2017, 18:58:25
Do kodu podłączać nie trzeba. "Tylko" wczytać wszystkie parametry z pliku fiz.
OK, zeby sie upewnic -- to, co jest zapisane w pliku .fiz pod identyfikatorem "WWList" powinno byc umieszczone w tablicy DElist w TMoverParameters, tak? I jeszcze taki kwiatek -- parametr Size jest o 1 mniejszy niz liczba wpisow, np:
WWList: Size=11
496 0 0 0
496 30 870 3000
496 75 870 3000
496 105 870 3000
496 135 870 3000
568 213 870 3000
640 305 870 3000
712 395 870 3000
784 495 870 3000
856 595 870 3000
928 705 870 3000
1000 800 870 3000
END-WWL

jak to interpretowac? Ignorowac pierwsza linie, czy Size?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: youBy w 20 Stycznia 2017, 19:00:24
Wiersze są ponumerowane od 0 do size, czyli jest ok ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 20 Stycznia 2017, 20:06:26
Wiersze są ponumerowane od 0 do size, czyli jest ok ;)
Ale dla normalnego czlowieka nie-programisty to nieintuicyjnie jest ;)
Tabela sie teraz laduje i wydaje sie, ze silnik na obroty wchodzi jak trzeba, wkazniki sie ruszaja itp, ale nie rusza dran z miejsca. Ktos kumaty musialby porownac to co tam jest w c++ z tym co jest w oryginale, moze cos zostalo nie popdpiete, idk.

edit: chyba znalazlem. funkcja ladujaca .fiz nie odzytuje niektorych parametrow (FTmax itp) i wszystkie zostaja na domyslnym 0.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: youBy w 20 Stycznia 2017, 20:47:33
Tak na dobrą sprawę, to można size usunąć, o ile zmienna rozmiaru tabelki będzie sukcesywnie powiększana podczas wczytywania. Sęk w tym, że nie będzie to do końca kompatybilne wstecz.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 20 Stycznia 2017, 21:46:30
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:

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 20 Stycznia 2017, 21:56:23
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ć.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: youBy w 20 Stycznia 2017, 22:46:02
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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 20 Stycznia 2017, 23:29:42
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)
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)
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?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: youBy w 21 Stycznia 2017, 09:18:21
To wszystko wynika stąd, że zmienne są współdzielone między różnymi rodzajami silników.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 21 Stycznia 2017, 17:12:06
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?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 21 Stycznia 2017, 21:37:38
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?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 22 Stycznia 2017, 11:09:33
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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 22 Stycznia 2017, 17:18:56
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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 22 Stycznia 2017, 19:06:20
Dopiero jak wrócę do domu. Teraz w gościach bawię się w domowego informatyka.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 23 Stycznia 2017, 04:50:51
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 ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 23 Stycznia 2017, 07:02:15
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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 23 Stycznia 2017, 10:33:03
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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 23 Stycznia 2017, 12:06:50
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ć.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 23 Stycznia 2017, 14:04:39
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 ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 23 Stycznia 2017, 15:36:23
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 ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 23 Stycznia 2017, 19:16:55
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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 24 Stycznia 2017, 07:44:52
Tak specjalnie zrobiłeś pull-a na mastera a nie na mover_c++ ???
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 24 Stycznia 2017, 10:01:17
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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 24 Stycznia 2017, 11:17:26
Aha, przy okazji. Nie bede robil kolejnego commita tylko dla takiego drobiazgu, ale jak mozesz to zmien deklaracje w VBO.h na:
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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 24 Stycznia 2017, 11:31:59
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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 24 Stycznia 2017, 12:50:25
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 ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 24 Stycznia 2017, 16:41:55
Testów nie będzie, gdyż nie kompiluje projektu ze względu na 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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 24 Stycznia 2017, 17:44:07
W PyInt.h zmien

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

i powinno pomoc.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 25 Stycznia 2017, 07:50:42
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 :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 25 Stycznia 2017, 16:29:49
Najnowsze exe to sprawdzenia. Tmj twierdzi, że część błędów już nie powinna być obecna.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: RoboBatman w 25 Stycznia 2017, 17:27:21
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:
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 25 Stycznia 2017, 17:30:36
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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 25 Stycznia 2017, 17:43:44
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
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 25 Stycznia 2017, 18:10:29
Wymaga redist-a także dla release? Hmmm...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 25 Stycznia 2017, 19:27:36
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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 25 Stycznia 2017, 19:53:57
Na czas testów można by włączyć.
Sypie się na zapisie e3d. W dziwnym miejscu bo ma out_of_range na t.substr(t.rfind). Trzeba też sprawdzić ukrotnienie bo RoboBatman zgłasza wysyp.
Już wiem, szukanie rozszerzenia kończy się wartością npos, która na substr zwraca właśnie out_of_range.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 25 Stycznia 2017, 20:25:23
W siódemce nie działa odluźniacz (6 na klawiaturze numerycznej). Animuje się przycisk, jednak nie spuszcza z cylindrów powietrza. Ciśnienie pozostaje na 4,4. Na innych pojazdach nie wiem. Zagrypiłem się na maxa, nie idzie testowanie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 25 Stycznia 2017, 20:26:50
Trzeba tez chyba zerknac na wyswietlanie ladunku w wagonach, bo np. 163 pokazuja pasazerow w oficjalnym .exe, a w tej same scenie w nowym sa puste.

Tak przy okazji, to w plikach .mmd do tych wagonow jest blad -- wpis lowpolyinterior: jest umieszczony przed animations: i w rezultacie w ogole nie laduje animacji do nich.

ale z drugiej strony, z pozytywnych rzeczy to po poprawce .mmd dziala animacji drzwi. Tzn. normalnie to nie dziala, bo laczenie domyslne to sprzeg + pneumatyka, i nie przekazuje sygnalow kontrolnych, ale jak sie to obejdzie, to wszystko chodzi ;)

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 25 Stycznia 2017, 22:32:25
Znalazlem, co bylo nie tak z brakiem ladunku w wagonach -- po prostu loader .fiz nie mial wpisanego przekazania akurat tej zmiennej do docelowego obiektu. W sumie zemscilo sie lenistwo, gdybym przerobil wszystkie sekcje, zeby uzywaly nowej wersji funkcji, to pewnie by to wyszlo, a tak przegapilem :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 26 Stycznia 2017, 03:00:47
Znalazl sie tez blad w odluzniaczu. W oryginale w Pascalu bylo
procedure TBrake.Releaser(state: byte);
begin
  BrakeStatus:=(BrakeStatus and 247) or state*b_rls;
end;

w tlumaczeniu bylo

BrakeStatus = (BrakeStatus & 247) || state * b_rls;

a powinno byc

BrakeStatus = (BrakeStatus & 247) | ( state * b_rls );

bo w C++ logiczne or czyli || i or bitowe czyli | to sa dwie rozne operacje. Ot tak, zeby latwiej sie bylo powiesic ;d

(tak na 90% ten blad wyskoczy jeszcze pewnie gdzie indziej, bo wystapil co najmniej w dwoch przupadkach, ale wybitnie nie chce mi sie czesac calego pliku zeby sprawdzic czy aby na pewno. Moze kiedys)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 26 Stycznia 2017, 07:02:13
No ten ostatni to mojsza błęda. W zasadzie te kwiatki powinny występować tylko przy brakestatus więc to można łatwo sprawdzić.
Na pocieszenie exe c6 z poprawionym wysypem na zapisie e3d oraz szukaniu eventów skanowanych. Nie ma poprawek tmj (jeszcze).
W archiwum glew.dll a w exe brak zależności od plików ze strony microsoftu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 26 Stycznia 2017, 19:26:43
Polaczylem i pchnalem poprawki z mojej strony. Jesli to mozliwe, to na przyszlosc chyba dobrze byloby przesunac pliki visual studio do "untracked files" w zakladce git'a (przeciagnij je z "Included Changes" do "Untracked Files" i VS bedzie to juz pamietal) bo inaczej bedziemy je sobie na przemian nadpisywali, co jest troche bez sensu :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 26 Stycznia 2017, 20:20:34
W 2015CE nie ma tej opcji :(
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 26 Stycznia 2017, 20:26:16
A to widac cos pozmieniali :/  to mozna chyba tez przelaczyc w .gitignore, te trzy linie:
*.sln
*.vcxproj
*.filters
trzeba je tylko odkomentowac. na 100% nie jestem pewien, ale powinno pomoc, moze byc tez potrzebne git rm tak jak to opisali tutaj: https://www.visualstudio.com/en-us/docs/git/tutorial/ignore-files ale warto sprobowac.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 27 Stycznia 2017, 00:46:30
Sprobowalem zaladowac Kaliska do nowego .exe, ale glupial na starcie bo nie mogl rozgryzc ukladu torow przy niezainicjalizowanych zmiennych. Dopisalem wiec pelna inicjalizacje do kilku najczesciej uzywanych typow, zeby bylo bardziej jak w Borlandzie. Teraz uruchamia Kaliska gladko, i przy okazji obrotomierze przestaly sie glupio krecic na starcie. Przy odrobinie szczescia powinno to tez naprawic okazyjny blad z kamera robiaca caly czas powolny zoom.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 27 Stycznia 2017, 08:05:29
Ja się wk... i robię refactoring tabelki prędkości bo to co jest jest nienaprawialne. Nie musisz robić pull-a. Mam Cię jako remote i ewentualnie mogę sam robić merge-a. Wystarczy, że wyślesz na serwer zmiany.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 27 Stycznia 2017, 22:52:22
Wymienilem tablice Dynamics w torach na deque z stl -- efektow negatywnych nie widac, natomiast ma to potencjalnie pozytywny efekt usuniecia limitu 40 pojazdow na tor.

edit: podmienilem kilka dodatkowych drobiazgow i poprawilem kilka malych bledow. Grubszych spraw na razie nie ruszam, zeby nie kolidowalo z tymi zmianami skanowania, czy co tam robisz.

Dolaczona wersja .exe ma wbudowana poprawke na czytanie cudzyslowow w plikach konfiguracji, jesli ktos chce sie bawic w testowanie uaktualniania konfiguracji do standard yaml. Albo inne testy :)

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.

edit 2: poprawka, bo z rozpedu dolaczylem stara wersje. Tak to jest jak sie trzyma plik binarny w innym katalogu ;/
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: szogun w 30 Stycznia 2017, 08:31:32
Zastanawia mnie czemu pierwsze wczytanie TD trwa 4-6 sekund, a za drugim razem to już tylko sekunda? Exe z ostatniego załącznika nie działa, winda się pluje że nie jest prawidłową aplikacją.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 30 Stycznia 2017, 09:06:35
Bo ma wszystkie assety na ramie. Zawsze kolejne wczytywanie tego samego było szybsze.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 30 Stycznia 2017, 16:28:29
Exe z ostatniego załącznika nie działa, winda się pluje że nie jest prawidłową aplikacją.
Hmm a jaka to wersja windy? Kompilowane bylo z ustawieniem od Visty w gore, nie wiem, czy pojdzie na czyms starszym.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Sowik2 w 30 Stycznia 2017, 16:33:02
No właśnie, a u mnie (niestety) jeszcze poczciwy Xp-ek.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 30 Stycznia 2017, 16:52:01
OK, przekompilowalem z ustawieniem na xp i nowsze. Nie wiem, czy cos zmieni, ale miejmy nadzieje, ze tak.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 30 Stycznia 2017, 18:59:22
Wsparcie dla xp ma być albo zwijam zabawki. :D Zaraz przetestuję czy działa.
Nie działa. Nieprawidłowa aplikacja Win32.
A Mariusz prosi o kompatybilność w Win98 SE. ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 30 Stycznia 2017, 19:27:28
Ściągnąłem z ciekawości i odpaliłem TD - wygląda, że działa, nawet sobie pojechałem. Rzuciłem więc exeka na głębszą wodę i spróbowałem odpalić swoją scenerię, ale niestety program się wywala - wygląda na to, że wysypuje się na wczytaniu tekstury *.bmp. Dotyczy zarówno exeka @tmj pod xp, jak i 483c6 od @firleju.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 30 Stycznia 2017, 19:30:27
No zesz koorna, to juz nie wiem. Kompilacja chyba ma domyslnie wlaczone uzywanie SSE w procesorze i takie tam, ale jesli w ogole, to by chyba raczej powodowalo inny rodzaj bledow. Nie mam tu xp, wiec nie moge sprawdzic. A ta wersja co ja firleju robi uruchamia sie u Ciebie?
Moge przestawic kompilacje na 98se, ale jak nie widzi tego jako prawidlowa aplikacje, to bedzie sztuka dla sztuki ;/

fake edit: przyjrze sie ladowaniu bmp przy okazji, choc tam chyba nic nie bylo ruszane.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 30 Stycznia 2017, 19:42:29
exec++ się nie uruchamia, wyświetla nieprawidłową aplikację na winxp. Otwierane przez rainsted, brak kompletnie reakcji.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 30 Stycznia 2017, 19:43:46
C6 od Firleja działa.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 30 Stycznia 2017, 19:53:28
Firlej, ustawiales cos extra w parametrach kompilacji?

Ladowanie BMP faktycznie wyglada na skopane, ale tak juz mial 'od urodzenia' -- funkcja traktuje wszystkie pliki jako 24bit, tak ze jak cos ma alpha channel, to sie sypie i w najlepszym wypadku wychodzi sieczka. Poprawie to troche w miedzyczasie, przynajmniej minimalnie, w dekompresje RLE raczej bawic sie nie bede.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 30 Stycznia 2017, 20:11:23
C6 działa, nawet jakoś ładniej się wczytuje i wygląda. Nie no, nadal nie ma naprawionego odluźniacza, dlatego chciałem to od tmjota;) Co do BMP, nigdy nie było wysypów na teksturach BMP, więc jeśli od urodzenia co tam jest nie tak, to jest to wiadomość zaskakująca. No chyba, że mnie przy czymś nie było i przegapiłem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 30 Stycznia 2017, 20:21:40
Dokonałem eksperymentu i przekonwertowałem sobie teksturę do *.dds, zostawiając ten sam model - teraz działa na obu exekach. Zatem faktycznie coś jest nie tak z ładowaniem tekstur *.bmp.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: guest23436 w 30 Stycznia 2017, 20:34:48
Czy było coś zmieniane w animacji patyków? W mojej EP02 - 08 nie podnoszą się, co na starym exe się działo.
Albo ja czegoś nie umiem, albo nie da się na tym exe (exe++) ruszyć ganzem i SM04.

Poza tym bez zarzutów.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 30 Stycznia 2017, 20:42:23
OK, pogrzebalem troche i okazalo sie, ze do kompilacji dla xp jest osobne ustawienie w vs2013. Przelaczylem i skompilowalem jeszcze raz, jesli mozesz to sprawdz, czy robi to jakas roznice?

Ladowanie BMP jest poprawione. Uwaga: tekstury BMP musza byc zapisane bez kompresji, a dodatkowo w porownaniu do .dds sa obrocone w pionie. W sumie chyba wygodniej Ci bedzie pracowac z TGA/DDS, ale przynajmniej nie powinno sie na nich teraz wysypywac.

edit: sn61 w testach ktore robilem dzialal, ale trzeba dosc dlugo przytrzymac rozruch zeby zaskoczyl. SM03 moze miec klopoty, bo w ogolnym kodzie hamulcow czy czego tam jest blad ktorego jeszcze nie poprawilem (w szczegolnych sytuacjach dochodzi do wyciagania pierwiastka z liczby ujemnej i cala symulacja glupieje)  EP02 nie mam, wiec nie wiem, ale pozostale dzialaja normalnie, po zalaczeniu baterii.

edit2: hmm sprawdzilem dla pewnosci i masz racje, teraz nie odpala. sprawdze co tam w miedzyczasie popsulem ;/
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 30 Stycznia 2017, 20:55:15
Odpala na winXP, tu jest ok, natomiast ganz ni huhu. Coś jest zepsute w stosunku do C6, bo tam ganz ładnie pali.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 30 Stycznia 2017, 21:02:29
Nadal się wysypuje na BMP, ale umówmy się, że a) nie jest to istotny bład; b) nie sprawdzałem, czy ten plik spełnia warunki, o których piszesz. Jedyne co mnie dziwi to fakt, że na poprzednich exe z tymi plikami działało to bez problemu. Pracuję na BMP jako teksturach roboczych, bo taki plik najszybciej można poprawić w razie potrzeby, ale i tak muszę je w końcu skonwertować do TGA/DDS, więc jest to do przeżycia.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 30 Stycznia 2017, 21:04:18
Jesli to nie problem to doczep ten plik .bmp ktory sprawia problemy do tego watka, zerkne pozniej co z nim moze byc nie tak.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 30 Stycznia 2017, 21:25:18
Musiałem spakować, bo forum nie łyka BMP.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 30 Stycznia 2017, 22:06:32
Na XP działa. Dziewiątka AI się uruchomiła, przejechała do wyjazdowego z TD i zahamowała bez problemów. Pod F1 w debugu jest fps zamiast diagnostyki, ale to zapewne zamierzone.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 30 Stycznia 2017, 22:09:59
@tmj, do planowanych zmian i myśli proponuję założyć osobny wątek bo tu się dużo rzeczy traci.
Trzeba by wyczyścić repo z nieużywanych plików, lub ewentualnie przenieść je do jakiegoś osobnego katalogu. To są wszystkie pascalowe plus parę z c++. Co proponujesz?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 30 Stycznia 2017, 23:17:01
Ten plik BMP ma naglowek w nowszym standardzie i wiekszy niz to, czego maszyna oczekuje, dlatego szedl w maliny. Wstawilem test dla bezpieczenstwa, wiec sie juz nie wywali przy ladowaniu, ale i tak nie obsluguje tego pliku zbyt dobrze. W sumie TGA/DDS beda mniej problematyczne, jesli Ci to nie przeszkadza.

Doszedlem, czemu spalinowe nie dzialaja. Zrobilem zle zalozenie przy odczycie DList, i wylazlo przypadkiem po zmianie kodu parsera. W sumie dziwne, ze dzialalo przedtem :)  Poprawione, znowu chodza. Uaktualnione .exe w zalaczniku.

Co do watku, chyba jak najbardzie. Co do zmian -- ja tu w sumie tylko troche sprzatam ;)  podlacz z moich poprawek ktore chcesz, poukladaj pliki tak, jak Ci pasuje, a ja sobie sciagne zmiany i sie dostosuje.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 30 Stycznia 2017, 23:22:39
Zgadza się, ganz odpalił. Dajcie znać jak publikacja będzie wspólna, bo tak to trochę rozczep jaźni jest co gdzie i u kogo. Aha, odluźniacz działa. Jakby ktoś pytał, ukończyłem pięknie Bałtyk.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 30 Stycznia 2017, 23:34:43
Ja na razie zastopuje z moimi -- pchnalem najnowsza wersje do Gita, tak ze Firleju moze sobia spokojnie zrobic to, nad czym pracuje, polaczyc te wersje i poustawiac pliki, a potem sie zobaczy :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 30 Stycznia 2017, 23:59:00
Poproszę o łopatologiczną instrukcję kompilacji. Jaka wersja VS by to działało. Co poustawiać w opcjach projektu by było dobrze. Krzyś będzie za mną łaził z bajerami od Q, to wypadałoby ogarnąć kompilację w nowym środowisku. Najlepiej w nowym wątku to.
Problem z większym nagłówkiem ma też rainsted. Wyprosiłem u Ra konwerter do starszego formatu. Tylko tam jest to problem używania bibliotek systemowych do obsługi bmp, przez co na XP nie czytało mi plików zrobionych w nowych paintach.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 31 Stycznia 2017, 00:02:45
Zapomnialem w rozkladzie zamiast bałtyk bylo ba,tyk. Takze nazwa pod f1 byla tak znieksztalcona.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 31 Stycznia 2017, 00:52:41
O ile sie nie myle to pliki projektow sa na chwile obecna w obu wersjach zrodel -- w mojej dla VS2013, u Firleju do VS2015. Tak ze teoretycznie wystarczy sciagnac wersje pasujaca do wersji VS ktora masz, i zaladowac plik maszyna.sln w Visual Studio. Moze byc tez potrzebna instalacja directX SDK ze strony Microsoftu, zeby dalo sie dolaczyc .lib do dzwieku. Sciezki do bibliotek itp w zasadzie powinien wszystkie miec, ale jesli trzeba to mozna je dopisac we wlasciwosciach projektu, jak na zalacznikach.

Litery w rozkladach u mnie tez sa dziwne, ale zalozylem ze to dlatego, ze u mnie jest angielskojezyczny windows bez polskich liter, i on ma kodowanie plikow ascii inaczej niz wersja polska. Jezeli tak samo jest w wersji kompilowanej w polskim systemie, to trzeba bedzie szukac przyczyn.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 31 Stycznia 2017, 08:06:22
Plik silucji maszyna.sln jest w wersji VS2013, ale to nie ma większego znaczenia, gdyż VS od wersji 2010 nie konwertują wersji na nowszą tylko używają starszej. Kompilowałem na VS2013, VS2015 i VS2017 na tej samej solucji i nie ma problemów z tym.
Zalecane jest VS2013 i w górę ze względu na rozpoczęcie używania c++11 w kodzie i na VS2010 raczej się już nie skompiluje.
Wszystkie potrzebne pliki .lib są na repo i nie powinno być problemu.
Największe różnice polegają na ustawieniu debugera, żeby korzystał z katalogu maszyny i ewentualnej nazwy generowanego exe i to może nadpisywać solucję. Ogólna zasada jest obecnie taka, że ściągasz repo, zmieniasz na parametry tobie potrzebne i nie wgrywasz na repo zmian, o ile nie dodasz jakiegoś nowego pliku.
Z racji powyższego zastanawiam się czy nie przejść na CMake lub coś podobnego.
Na nasze potrzeby jest wystarczająca wersja CommunityEdition.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 31 Stycznia 2017, 21:54:17
Odpaliłem swoją scenerię na eu07++, BMP wszystkie przeszły i wygląda, że przynajmniej na starcie działa. Z rzeczy widocznych na pierwszy rzut oka:
- EN57 mimo ustawienia prędkości początkowej 0.1 nie uruchamiają się;
- program wywala następujące błędy, których nie wywala exe 481:
Failed to load 3d model "dynamic\pkp\1xxa_v1\passengers.t3d"
Failed to load 3d model "dynamic\pkp\z1_v2\passengers.t3d"
Failed to load 3d model "dynamic\pkp\en57_v1\przedsionki.t3d"
Failed to load 3d model "dynamic\pkp\en57-2000_v1\przedsionki.t3d"
- po paru minutach program się wysypuje nawiązując tym samym do światłych tradycji swych przodków ;) Wygląda na to, że problemem jest próba wykonania eventu "copyvalues" (przy trzech próbach właśnie tam kończył się log):
event jan_osob_nadajrozklad_tor11_osobI copyvalues 0.0 jan_osob_g_sem_mem jan_osob_rozkladosob endeventgdzie jan_osob_rozkladosob ma wartość jak poniżej:
event osobA_rozklad1239 updatevalues 0.0 jan_osob_rozkladosob Timetable:slimson/calkowo_v2/ROPr55415 10 0 endevent
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 31 Stycznia 2017, 23:40:55
Brakujace modele to nic nowego, po prostu do tej pory .exe nie traktowal tego jako blad warty zgloszenia ;)

Po sprawdzeniu EN57 faktycznie wyglada na martwy. Tzn recznie jezdzi bez problemu, ale jesli wlacze AI to wyglada na to, ze ono w ogole nie probuje sterowac. Nie pamietam czy wczesniej sobie radzilo, w kazdym razie do sprawdzenia.

Eventow i komorek pamieci w zasadzie jeszcze nie ruszalem, wiec tam sie moze dziac wszystko.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 31 Stycznia 2017, 23:50:46
Przedsionki byłyby do wywalenia kiedyś przy okazji, bo ich sztywne ładowanie we wszystkich ezt to głupota. Są tożsame z lowpolyint i cab 2&0.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 01 Lutego 2017, 04:33:26
Przyjrzalem sie EZT, i wychodzi na to, ze winny jest bajzel :)

* do prawidlowego dzialania zespolu wymagane sa minimum: polaczenie wys. napiecia i "polaczenie fabryczne" czyli flaga 128, miedzy czescia sterujaca i czescia silnikowa.
* zestawy w sceneriach sa typowo laczone kombinacja 55, ktora nie przenosi zadnej z tych dwoch flag.
* zeby bylo smieszniej, to plik .fiz dla EN57 (i pewnie pozostalych, nie sprawdzilem) definiuje AllowedFlag na 103 z jednej strony, i -119 z drugiej, co najwidoczniej kiedys dodalo by "polaczenie fabryczne" do podanej flagi, ale wartosci ujemne nie sa juz obslugiwane, i modul dostaje 103 na obu koncach.

w rezultacie, z punktu widzenia AI siedzi ono w wydmuszce bez zadnego silnika i pradu, wiec nawet nie probuje nic ruszac.

mozna to rozwiazac albo zmiana w pliku .fiz i podaniem wlasciwych AllowedFlag, z uwzglednieniem wartosci +8 i +128, i poprawieniem wpisow skladow w sceneriach, albo przywroceniem obslugi wartosci ujemnych (i poprawieniem wpisow skladow w sceneriach). Zakladam, ze wartosci ujemne przestano obslugiwac z jakiegos powodu, wiec nie bede sie spieszyl z wlaczaniem tego kawalka ponownie. Niech sie madrzejsi ludzie zastanowia, jak chca to miec zrobione ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 01 Lutego 2017, 06:53:08
Nie są obsługiwane ujemne na wczytywaniu czy na obsłudze? Jeśli to pierwsze to to jest błąd niezamierzony. Jeśli to drugie to coś namieszało przy konwersji, bo na pewno to powinno działać jak poprzednio.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 01 Lutego 2017, 07:42:28
Przy wczytaniu:

    if (fAllowedFlag > 0)
        Couplers[0].AllowedFlag = fAllowedFlag;
    if (Couplers[0].AllowedFlag < 0)
        Couplers[0].AllowedFlag = ((-Couplers[0].AllowedFlag) || ctrain_depot);
AllowedFlag jest zmieniana z domyslnej wartosci (0) tylko jest wartosc wzieta z pliku .fiz jest dodatnia. A potem sprawdzana jest juz wartosc docelowa, ktora w przypadku wartosci ujemnej w pliku .fiz zostaje niezmieniona, czyli w zasadzie ten drugi warunek nie wykonuje sie nigdy.

Jesli to pomylka to ok, poprawilem ta sekcje (przy okazji odczytuje tez odrebne parametry dla kazdego sprzegu jesli sa podane osobno, w oryginale kopiowal zawartosc pierwszego do drugiego) Chociaz AI w EZT specjalnie to nie pomoglo, bo teraz procedura wyszukiwania silnika znajduje co trzeba, i AI w kabinie kontrolnej glupieje w inny sposob ;)  Docelowo trzeba by chyba przerobic troche caly system, tak zeby kontrola stanu opierala sie o caly 'zespol trakcyjny' a nie tylko pojedynczy czlon. A czy ten 'zespol' to tylko pojedyncza lokomotywa, czy kilka sztuk albo czlonow spietych ze soba, i ktory konkretnie element napedza calosc, w to juz kod sterujacy wnikac nie musi.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 01 Lutego 2017, 09:18:51
W pascalowym moverze dozwolone flagi tyczyły się tylko sprzęgania w czasie symulacji. Wpisy z trainseta ignorowały te ograniczenia i można było sobie spokojnie ukrotnić dwie węglarki z przewodem ogrzewania i szyną WN.
Szyna WN była potrzebna tylko gdy kilka pojazdów miało napęd ale tylko jeden odbierak prądu. Przykładowo w ED72 przy podniesieniu jednego pantografu. EN57 ma pantograf i silniki w tym samym członie, wiec na 55 działał.
Flaga ujemna była tożsama z +256. Zresztą patrząc na diagnostykę te flagi wewnętrznie i tak przyjmowały inne wartości niż w trainsecie. Coś ukrytego było jeszcze dodawane. Nie wiem dlaczego Ra yB zdecydował się na ujemne zamiast jawnego +256 dla sprzęgu depotowego. Może uznał, że tak będzie czytelniej dla ustawiaczy i wygodniej przy zmianach.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 01 Lutego 2017, 09:30:16
Sprzęgi depotowe zrobił yB. Ogólnie cała konstrukcja sterowania pociągiem jest poroniona:
Wszędzie jest pełno odwołań bezpośrednio do zmiennych w danych klasach co powoduje, że wszystkie zmienne w mover są publiczne. Tak na wszelki wypadek.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: youBy w 01 Lutego 2017, 14:15:47

Ciekawie zaczyna się robić, gdy przeanalizuje się pracę nowoczesnych zespołów trakcyjnych w trakcji wielokrotnej. Jednostki centralne pojadów komunikują się ze sobą, natomiast każda z jednostek centralnych oddzielnie zarządza swoim pojazdem. Podsumowując: jednostka centralna pojazdu-mistrza wie wszystko o pociągu, zostawiając nieco autonomii pojazdom-niewolnikom w sterowaniu pojazdem.
W chwili obecnej w DynObj (z braku lepszego miejsca…) jest sterownik hamulca EP+ED dla asynchronów, który musi sterować oddzielnie każdym członem, zamiast zadać każdemu pojazdowi odpowiednią siłę hamowania. Każdy z pojazdów powinien mieć wgraną tabelkę blendingu (ile można dać hamulca ep przy pełnym ed), natomiast ja byłem zmuszony napisać algorytm, który robi to w czasie rzeczywistym i jest w stanie poradzić sobie z dowolną konfiguracją pociągu we wszystkich sytuacjach ruchowych (łącznie z poślizgiem pojedynczych osi) ;-)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 01 Lutego 2017, 16:27:56
Udalo sie prowizorycznie uruchomic EZT -- w kodzie ustawiajacym aktywna kabine byl blad, po usunieciu AI radzi sobie calkiem niezle. Oprocz tego, nie jestem pewien ale wyglada na to, ze domyslnie AI jest ustawione zeby nie ruszac niczego dopoki nie otrzyma rozkazow, a skanowanie/rozkazy nie zaczynaja byc wysylane dopoki pociag nie wlaczy przynajmniej baterii... wiec zdarzaja sie sytuacje typu kiedy AI czeka na sygnal I odwrotnie, I nic sie nie dzieje. Tymczasowo wylaczylem dla AI to oczekiwanie, I teraz zawsze sprawdza/uruchamia silnik, co popycha troche wszystko do przodu. Jesli to zly pomysl, to zawsze mozna cofnac ;)

Wyglada na to, ze jest klopot z SM42 -- sama jeszcze jezdzi, ale wydaje sie, ze nie ma zadnej sily pociagowej, I z przyczepionym wagonem stoi w miejscu (albo wchodzi w poslizg na zbyt wysokich obrotach) Nie wiem czy to przez zmiany w ladowaniu .fiz czy cos innego, przyjrze sie. Nie pamietam, czy wczesniej jezdzila lepiej.

Sklady AI czasami hamuja tez z duzym opoznieniem, ale to chyba tez ma zwiazek ze skanowaniem, wiec na razie nie ruszam.

Z innych rzeczy zrobilem przy okazji male przesuniecia w funkcji renderujacej, tak ze wszytkie uaktualnienia sceny sa teraz wykonane najpierw, a rysowanie na ekranie nastepuje potem. Samo w sobie nie robi to zadnej roznicy, ale otwiera pewne... mozliwosci.

(palpatine.jpg)

uaktualnione .exe w zalaczniku, dla sprawdzenia EZT, i co tam kto chce ;d
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 01 Lutego 2017, 16:56:53
Na scenerii Kaliska sm42 sama podpina sie w peronach do skladu 9 pudel i po otrzymaniu ms2 udaje sie w perony. W innej czesci scenerii wykonujemy manewry z pociagiem odstawczym, nie jest lekki. Ten lok zwawo sie rusza i do slabych nie nalezy. Jesli z jednym wagonem stoi, to jest zepsuta. EZT i kazdy pojazd w scenerii obsadzony przez AI na starcie, powinien miec wlaczona baterie. Chyba, ze zostal w tej scenerii umieszczony jako nobody. Brak checi zabrania sie ai do pracy bywal zawsze.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 01 Lutego 2017, 17:27:39
Na scenerii Kaliska sm42 sama podpina sie w peronach do skladu 9 pudel i po otrzymaniu ms2 udaje sie w perony. W innej czesci scenerii wykonujemy manewry z pociagiem odstawczym, nie jest lekki. Ten lok zwawo sie rusza i do slabych nie nalezy. Jesli z jednym wagonem stoi, to jest zepsuta.
No, okazuje sie ze to cos innego. Zmontowalem kilka roznych skladow i z tymi SM42 spisuje sie normalnie. Za to symulacja glupieje z zestawem Bhp -- pierwszy czlon jedzie, a reszta stoi jak wryta. Jak podpialem EU07 zamiast SM to prawie rozerwala sklad na pol o.O
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 01 Lutego 2017, 17:48:38
Pewnie coś ze sprzęgiem depotowym. Bhp są "nierozrywalne" we flagach.
Zachowanie ai zależało od prędkości. Dla v0=0 nic nie robił i czekał na rozkaz. Dla v0=0.1 się uruchamiał i skanował.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 01 Lutego 2017, 18:18:54
To sie objawia nawet przy polaczeniu standardowym czyli sprzeg + hamulec. Na pierwszy rzut oka podejrzewam, ze to moga byc parametry dla sprzegu typu Articulated -- czesc z nich jest mnozona przez Ftmax ktory domyslnie ma wartosc 0.0, a to chyba nie wplywa najlepiej na symulacje? (problem wylazi gdy jeden z wagonow Bhp stuknie o drugi)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 01 Lutego 2017, 18:36:23
Taki dziwny stan (nieustalony?) po stuknieciu juz bywal. Sprawdz czy cala bhp stoi na jednym torze, czy na dwu. Nie jestem przekonany czy to dobry trop, ale moze wylaza przy okazji jakies czary z dawnych czasow.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 01 Lutego 2017, 22:16:18
Blad sie znalazl. Jak zwykle, zemscilo sie przepisywanie parsera .fiz po kawalku :s  w rezultacie ustawial zbyt male niektore wartosci dla sprzegow articulated, i symulacja wariowala. Teraz jest juz ok.

edit: mala aktualizacja -- w EZT nie dzialala tez sprezarka. Teraz dziala, czyli koniec blogies ciszy w trakcie prowadzenia. Doczepiam .exe, bo przez chwile najprawdopodobniej sie nie zmieni, wiec lepsze takie, z mniejsza iloscia pluskiew.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 02 Lutego 2017, 20:07:41
Dodałem do bugtrackera kategorię Maszyna 2017>Mover C++ i dałem @tmj devsa tam by mógł moderować tickety. Nie wiem czy w wątku wam nie wygodniej, ale można korzystać.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 02 Lutego 2017, 20:48:38
Szkoda, że ten tracker jest o tyle ubogi, że nie ma w nim możliwości zdefiniowania kamieni milowych. Ba, tam nawet sortowania listy nie ma po kategoriach zgłoszeń...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: youBy w 02 Lutego 2017, 21:32:56
Tak przy okazji – będzie się komuś chciało od razu wprowadzić klasę wózek i klasę oś wraz z indywidualnym liczeniem nacisków, przyczepności i obrotów?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 02 Lutego 2017, 21:58:06
Chciec to moze by sie i chcialo, ale ja z fizyki kompletna noga jestem ;/ moglbym co najwyzej poprzestawiac to co jest metoda kopiuj/wklej, bez zadnej gwarancji ze to da rezultaty zblizone do oryginalu. Jesli mozesz cos takiego wyprodukowac albo znasz kogos, kto moze, to jak najbardziej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: youBy w 02 Lutego 2017, 22:07:31
Niestety, obecnie tego w symulatorze nie ma. W tym momencie jeden pojazd (Mover) musi mieć dwa wózki, a wszystkie osie kręcą się z tą samą prędkością. Formę docelową mógłbym rozpisać na kartce w bloczkach/pseudokodzie (co można zrobić właściwie wszędzie), natomiast do kodowania potrzebny jest już komputer ze źródłami i kompilatorem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 02 Lutego 2017, 22:20:10
Teoretycznie wózek jest. Ale raczej tylko do śledzenia toru i wyświetlania grafiki, tudzież wyzwalania eventów.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 03 Lutego 2017, 18:11:49
Na ostatnim exe07++ EN57 się odpalają, ino drzwi nie otwierają przy postoju. Nie wiem jeszcze, czy jeżdżą, bo znowu wykonał mi się event "copyvalues", symulator znowu się wysypał, ale dorzucił w gratisie nowy, ciekawy błąd - screen w załączeniu. Zdaje się, że to efekt próby wykonania tego crashdumpa. Plik dbgHelp.dll z paczki wrzuciłem do folderu z MaSzyną, on ma być może w jakiejś konkretnej lokalizacji?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 03 Lutego 2017, 18:51:56
Nie jestem pewien -- z tego, co moge wyczytac to byc moze twoj Windows juz ma zainstalowana wlasciwa wersje tej biblioteki, i ta ktora dolaczylem mu nie pasuje. Sprobuj wyrzucic ja z folderu (w ten sposob OS bedzie sie musial posluzyc tym, co ma dostepne systemowo) i zobacz co sie stanie jak .exe wysypie sie kolejny raz?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 03 Lutego 2017, 19:22:19
Podziałało. W załączeniu spakowany crashdump.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Bochi w 03 Lutego 2017, 20:20:37
Hej, jestem tu nowy i jeśli to niewłaściwy wątek to przepraszam, ale znam C++11, ObjectPascal i chciałbym dać jakiś wkład w symulator. Chciałbym spytać, czy mogę w jakiś sposób pomóc, a jeśli nie tu, to czy są jakieś "drobniejsze" prace w których mógłbym się przydać. Zależy mi przede wszystkim na nauce. Dzięki :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 03 Lutego 2017, 20:22:09
Cos jest na pewno na rzeczy z copyvalues (i prawdopodobnie eventami w ogole), bo podobny problem wystepuje np. na linii61_osobowy1 ktora wykrzacza sie prawie na samym poczatku, rowniez na evencie tego typu, ktory jakims sposoboem nie ma w ogole zainicjowanych parametrow. Ale system eventow jest zakrecony jak baranie kiszki i nie bardzo wiem czy warto brac sie za ich rozplatywanie, bo podejrzewam ze Firleju sie z przyjemnoscia pozbedzie tego w calosci, jak przyjdzie do rekonstrukcji tej czesci program ;)

edit:
@Bochi, zrodla symulatora sa na Githubie (aktywne galezie do wejrzenia tutaj: https://github.com/eu07/maszyna/network )  obejrzyj sobie, i na pewno znajdzie sie cos, co zechcialbys poprawic.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 03 Lutego 2017, 20:35:52
Myślę, że przejście na system post-eventowy to kwestia na tyle odległa, że warto byłoby jednak spróbować te baranie kiszki rozprostować, na ile się da :) Choćby dla kompatybilności wstecznej, bo zanim wszystkie scenerie zostałyby przepisane na nowy wariant sterowania, też minęłoby sporo czasu. Poza tym bez w pełni działających eventów ciężko będzie dobrze przetestować nową wersję exe i wyłapać wszystkie kwiatki.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 03 Lutego 2017, 20:47:37
Co prawda to prawda. Jest gdzies w ogole jakis opis, jak eventy maja (w teorii funkcjonowac) w wersji obecnej? chcialem sprawdzic na wiki ale od paru dni serwer na ktorym lezalo eu07.es chyba nie zyje ;/
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 03 Lutego 2017, 20:55:28
Eventy masz opisane na wiki Ra. Na wiki Q było kopiuj-wklej o ile wiem. Może trochę przeredagowane przez Firleja. Mam nadzieję, że Q opłaci serwer i wiki wstanie. Teraz jak mam ftp eu07.pl mogę przenieść wszystko tu, tylko musi mi się chcieć. Zdaje się nawet jakieś mediawiki jest już wgrane.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Sowik2 w 03 Lutego 2017, 21:17:30
Coś dalej jest nie tak z tym parserem. Wszystko się ładuje, ale wywala błędy (za każdym razem te same, ale nie wszystkie, które na logikę powinno wywalić) tak np.
Missed sound: [1007]estluz.wav 50
Missed sound: [1007]estluz.wav 50
Tymczasem w pliku jest jeszcze jeden dźwięk z dodanymi cudzysłowami, ale jego nie wywala mimo, że cudzysłowy są dane w tych samych miejsch.
unbrake: "[1007]estluz.wav 50"
brakeacc: "[1007]est_bac.wav 50"
Dodam, że tych dźwięków, które wywali, nie słychać. Nie wiem od czego to zależy. Czyli jedno parsuje poprawnie, a drugie w całości bierze jako nazwę.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 03 Lutego 2017, 21:47:36
Eventy masz opisane na wiki Ra.
Na wlasnie nie bardzo. Na stronie Ra w scenery.doc jest w tekscie link Eventy, a gdy go klikne to dostaje tylko
Cytuj
Ta strona została usunięta. Rejestr usunięć i zmian nazwy tej strony jest pokazany poniżej.
22:17, 11 lis 2014 Ra (dyskusja | edycje) przeniósł stronę Symulator/MaSzyna/Eventy na Symulator/MaSzyna/Pojazdy, bez pozostawienia przekierowania pod starym tytułem
I na stronie docelowej o eventach nic nie ma. Sam event ma 13 parametrow w jednej tablicy, i kod je tam sobie wedlug wlasnego widzimisie przestawia/kopiuje itp, ale dlaczego akurat te a nie inne to raczej czarna magia, wiec trudno dojsc czy akurat robi cos blednie.

@Sowik, trudno powiedziec czy to jest parser, czy na przyklad funkcja ktora probuje zaladowac dzwiek nie wyczynia czegos z argumentem, ktory dostaje. Czy to jest na jakiejs okreslonej scenerii z paczki calosciowej? Najlepiej jakbym mogl to przesledzic u siebie, co on tam robi.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 03 Lutego 2017, 21:50:39
A tak technicznie jak to działa od strony kodu to niestety nigdzie nie było opisane.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Sowik2 w 03 Lutego 2017, 21:57:49
@tmj, jutro spakuję Ci zestaw tych plików, a testowałem na td.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 03 Lutego 2017, 22:31:33
Parametry eventów można odczytać tylko na podstawie tego do którego akurat odnosi się w danym miejscu i co z nim robi. ZTCP to coś koło 8, 9 to jest memcell, wartości. Pierwsze to chyba położenie. Nigdy nie odgadłem co kierowało tym gościem co to zaprojektował.

Z innych rzeczy. Tabelka jest niepoprawialna. Jedynym sposobem, żeby dobrze działała to jest wiązanie eventów do torów, które stoją obok. Przy okazji na Sieradzu po zmianie wiązań eventów udało mi się znaleźć powtarzalny efekt nie widzenia w4.
Żeby poprawić tabelkę na elastyczną należy zmienić cale SpeedPosTable na unordered_map i sortować po trasowaniu torów. Ponadto dodać możliwość przypisywania więcej niż jednego eventu w danym punkcie (np. dwa eventy1) i wszystkie zmiany, które się z tym wiążą. Szczerze? Łatwiej chyba zaprojektować to od nowa.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 03 Lutego 2017, 22:43:38
@tmj, jutro spakuję Ci zestaw tych plików, a testowałem na td.
OK, bede wdzieczny.

W miedzyczasie udalo sie chyba, odpukac, poprawic blad z copyvalues. Na szczescie to chyba nie bylo w samym kodzie eventu, ale przy pobieraniu danych do logowania -- po zmianach w wersji 464 jedna procedura byla uzywana dla dwoch typow eventow, ale w przypadku copyvalues tych danych do pobrania po prostu nie bylo. Teraz powinno byc w porzadku, uaktualnione .exe dolaczone, do sprawdzenia.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 03 Lutego 2017, 23:41:41
Na wlasnie nie bardzo. Na stronie Ra w scenery.doc jest w tekscie link Eventy, a gdy go klikne to dostaje tylko
Cytuj
Ta strona została usunięta. Rejestr usunięć i zmian nazwy tej strony jest pokazany poniżej.
22:17, 11 lis 2014 Ra (dyskusja | edycje) przeniósł stronę Symulator/MaSzyna/Eventy na Symulator/MaSzyna/Pojazdy, bez pozostawienia przekierowania pod starym tytułem
I na stronie docelowej o eventach nic nie ma.

W sensie... O tym mowa? http://rainsted.com/pl/Symulator/MaSzyna/Scenery.doc
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 04 Lutego 2017, 02:30:44
Tak, z tym ze mialem nadzieje ze na tej brakujacej stronie jest troche detail od strone .exe, ale wychodzi na to ze tego nigdy nie bylo... na szczescie przynajmniej na razie dalo sie obejsc bez takich szczegolow :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: matek123 w 04 Lutego 2017, 09:24:54
Trochę opisów eventów masz w instrukcji do event generatora.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 04 Lutego 2017, 09:40:15
tmj, byłoby miło, gdybyś takie lib-y tez wrzucał na repo. Jedyne jakie posiadam na dysku są od BCB.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 04 Lutego 2017, 09:53:15
Ale tu chodzi o wewnętrzną strukturę klasy Event, nie o opis działania.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 04 Lutego 2017, 14:55:50
Dobra, copyvalues już się nie sypie, ale za to wpadłem na kolejne ciekawostki:
- podwójne EN57 spięte ze sobą nie działają np. takie coś:
node -1 0 EN57-1641ra dynamic pkp\en57_v1 en57-1641ra 6baii 0.0 headdriver 55 0 enddynamic
node -1 0 EN57-1641s dynamic pkp\en57_v1 en57-1641s 6bsii 0.0 nobody 55 0 enddynamic
node -1 0 EN57-1641rb dynamic pkp\en57_v1 en57-1641rb 6bbii 0.0 nobody 55 0 enddynamic
node -1 0 EN57-1642ra dynamic pkp\en57_v1 en57-1641ra 6baii 0.0 nobody 55 0 enddynamic
node -1 0 EN57-1642s dynamic pkp\en57_v1 en57-1641s 6bsii 0.0 nobody 55 0 enddynamic
node -1 0 EN57-1642rb dynamic pkp\en57_v1 en57-1641rb 6bbii 0.0 nobody 0 0 enddynamic
endtrainset
Wygląda to tak, że stoi sobie taka bidula, patyczki ma podniesione, w ostatnim EZT są nawet końcówki włączone, ale w pierwszym świateł nie ma i wydaje mi się, że oba w ogóle nie są uruchomione (nie słychać sprężarek czy przetwornic). Pojedyncze EZT działają.

- nie działa odczytywanie / interpretacja / whatever rozkładów. W liście skanowanych torów pojawiają się co prawda stopinfo, ale zawsze z prędkością v=0, która jest i tak ignorowana. Jak pociąg wyjedzie na szlak, nie zatrzymuje się na przystankach. W konsekwencji nie działa też kierpoć.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Sowik2 w 04 Lutego 2017, 15:45:52
Przesyłam paczkę, w której jest kilka plików .mmd, które uważam, że są dobrze przerobione, exe, na którym testowałem i przykładowy log i errors.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 04 Lutego 2017, 17:57:24
to tak, że stoi sobie taka bidula, patyczki ma podniesione, w ostatnim EZT są nawet końcówki włączone, ale w pierwszym świateł nie ma i wydaje mi się, że oba w ogóle nie są uruchomione (nie słychać sprężarek czy przetwornic). Pojedyncze EZT działają.
Hmm u mnie dzialaja. Skopiowalem sobie zestaw z kaliska_cegielski, postawilem na TD, wlaczylem mu AI i kula sie bez problemow (screenshot na dowod) Z EN jest chyba ogolnie jakis dziwny blad ktory objawia sie od czasu do czasu -- zespol odpala sie normalnie, ale jak tylko ustawi sie kierunek do przodu/tylo, silnik wywala i tyle. Trudno to wylapac, bo trafia sie od czasu do czasu (czyli pewnie gdzies tam jest nieinicjalizowana zmienna albo cos)

Rozkladow/skanowania na razie nie ruszam w ogole, bo Firleju to ogarnia, wiec nie chce zeby sie bajzel zrobil.

Aha, i jakie .liby mam dolaczac? Nic dodatkowego nie dokladalem, jesli to dbghelp to ona sobie lezy w Windows SDK ktory przychodzi z VS, i linker ja sobie ciagnie z domyslnych sciezek.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 04 Lutego 2017, 19:15:05
@Sowik2, z tego co widze to problem raczej nie jest z parserem, a bierze sie z tego, jak uzywane sa cudzyslowy:

engine: "[1007]silnik_st45_1.wav  190.0  0.3 0.85  0.01 0.8"
takie cos powoduje, ze caly blok 6-u parametrow jest wciagniety jako jeden token, i podany jako nazwa dzwieku dla silnika. Takiego dzwieku oczywiscie nie ma, a dodatkowo kod glupieje, bo kiedy probuje odczytac 5 pozostalych parametrow poza dzwiekiem silnika, zaczyna brac dane z nastepnych linii, ktore sa konfiguracja pozostalych parametrow, i wszystko sie rozjezdza. Nie znam sie na YAML, ale w cudzyslowach powinien byc chyba tylko ten kawalek, w ktorym wystepuje klamra, tzn.:

engine: "[1007]silnik_st45_1.wav"  190.0  0.3 0.85  0.01 0.8

Oprocz tego, wylazl problem: YAML oznacza komentarze znakiem '#', a parser nie rozpoznaje tego jako komentarz. Mozna by to latwo zmienic, ale symulator uzywa znaku # do takich rzeczy jak #include itp. w pozostalych plikach, wiec jesli zaczyna je ignorowac jako komentarze, rozwala to cale ladowanie. Na chwile obecna "rozwiazaniem" jest nie umieszczanie komentarzy w plikach yaml.

edit: obszedlem to w inny sposob -- # jako komentarz jest rozpoznawane przez parser opcjonalnie, domylsnie wylaczone i w chwili obecnej aktywowane tylko w czasie ladowania plikow .mmd  Oznacza to, ze pliki te nie moga uzywac #include, ale chyba nikt tam tego nie stosowal..?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Sawi w 04 Lutego 2017, 19:41:00
Masz na myśli wpis include do t3d?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 04 Lutego 2017, 20:15:24
Ogolnie to mi sie poplatalo :)  wydawalo mi sie, ze w maszynie sa dyrektywy typu #include w plikach i dlatego przy uniwersalnym traktowaniu # jako znaku komentarza ladowanie szlo w maliny, ale on tam wystepuje w innym charakterze, chociaz efekt jest ten sam. Ogolnie to chyba # uzywany jest na tyle czesto, ze komentarze YAML trzeba bedzie sobie darowac. Albo zastapic # jako znak specjalny w konfiguracjach czyms innym.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 04 Lutego 2017, 20:20:31
...- nie działa odczytywanie / interpretacja / whatever rozkładów. W liście skanowanych torów pojawiają się co prawda stopinfo, ale zawsze z prędkością v=0, która jest i tak ignorowana. Jak pociąg wyjedzie na szlak, nie zatrzymuje się na przystankach. W konsekwencji nie działa też kierpoć.
Potwierdzam. Dodatkowo proszę o numerację kompilacji. Ciężko to później w paczce ponazywać i porównywać. Nadpisanie poprzedniego nie wchodzi w grę, w razie potrzeby porównania, rodzi to komplikacje. Może do nazwy C++ dodawać miesiąc i dzień kompilacji?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 05 Lutego 2017, 01:04:13
Udalo sie chyba poprawic W4, bez wlazenia w skanowanie itp -- bledy byly w pobieraniu i porownywaniu nazw przystankow z rozkladem. Prawdopodobnie ciagle moga wyskoczyc jakies krzaki przy stacjach z polskimi literami w nazwach, ale to wyjdzie w praniu.

Wlaczylem tez z powrotem rzucanie pudlem w widoku wewnetrznym. Nie jest identyczne, i prawdopodobnie przesadzone w porownaniu z rzeczywistoscia, ale o tym niech sie wypowiedza ludzie z rzeczywistym doswiadczeniem ;)

edit: iiiiiii poprawka, bo gdybym za pierwszym podejsciem czegos nie przegapil, to za dobrze by bylo. Teraz widzi co trzeba.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 05 Lutego 2017, 07:04:47
Krzaki wyszły przy wyświetlaniu. Ale porównuje OK, tzn kierpoć zadziałał na stacji "Ba,tyk". Symulacja uruchamia się z dźwiękiem włączenia hamulca awaryjnego, tak chyba nie powinno być. W przypadku kibla ten dźwięk odtwarza się bez końca i nie da się go wyłączyć.
Z różnic między starym exe a nowym (bo pierwszy raz testuję) - ładowanie scenerii jest jakieś 2x szybsze (Całkowo v2 ładuje się 2 minuty zamiast 4). Ciekawe czemu?
Coś ze sterowaniem jest nie tak, odpaliłem nową misję Bałtyk_en57 - ciężarówka przejechała przez szlaban i utknęła tam, zablokowała ruch, misja nieprzejezdna dzięki temu. Na exe 481 działa (chociaż kierpoć się wiesza).

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 05 Lutego 2017, 07:37:57
Jeszcze jeden bug: sterowanie hamulcem pomocniczym działa źle - wciskam Num1 raz, nic, dwa razy nic, trzy razy nic, cztery razy - hamulec przeskakuje nagle w pełne zahamowanie. Czyli brak możliwości regulacji siły hamowania.

(Sorki za drugi post, dopiero teraz zauważyłem, że forum nie scala.) Wybaczamy, liczymy na poprawę w przyszłości ;)     /@m.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Sowik2 w 05 Lutego 2017, 10:07:06
engine: "[1007]silnik_st45_1.wav"  190.0  0.3 0.85  0.01 0.8
Z tymi cudzysłowami próbowałem już kiedyś tak, jak mówisz, ale potem parser yaml-owski nie wie co zrobić z resztą parametrów.  Mam pewien pomysł, ale sprawdzę go chyba dopiero jutro.
A jeżeli chodzi o komentarze, to można by było zrobić (a może już jest, proszę o link) plik, w którym jest cały opis pliku mmd ze wszystkimi parametrami i ich przeznaczeniem, a te komentarze usunąć, bo jest dużo niepotrzebnych. Natomiast nie wiem co z parametrami odkomentowanymi.
Przesyłam specyfikację YAML 1.2 może się do czegoś przyda.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 05 Lutego 2017, 12:26:05
Apropos W4, to dziwię się że coś wyszło gdyż to była pierwsza rzecz jaką konwertowałem i testowałem wtedy te zmiany. Błee, co za syf.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 05 Lutego 2017, 13:08:03
Coś ze sterowaniem jest nie tak, odpaliłem nową misję Bałtyk_en57 - ciężarówka przejechała przez szlaban i utknęła tam, zablokowała ruch, misja nieprzejezdna dzięki temu. Na exe 481 działa (chociaż kierpoć się wiesza).
Ta ciężarówka ma problem z hamulcami od zawsze, więc to z exe raczej nie ma nic wspólnego. No chyba, że by zrobić ai uwzględniajace za słabe hamulce przy kalkulacji drogi hamowania. ;)

Jakiś komentarz w mmd by się jednak przydał. Przy testach wpisów dobrze mieć możliwość zachowania starego w pliku, by móc się cofnąć jak coś nie bangla.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 05 Lutego 2017, 17:34:56
Z różnic między starym exe a nowym (bo pierwszy raz testuję) - ładowanie scenerii jest jakieś 2x szybsze (Całkowo v2 ładuje się 2 minuty zamiast 4). Ciekawe czemu?
Bo wymienilismy parser na ten, o ktorym wszyscy mowili, ze bedzie za wolny ;)

A tak na serio, to przez 10 lat z okladem od czasow Borlanda kompilatory poprawily sie w optymalizacji, wykorzystywaniu nowych instrukcji procesorow, itp.

Cytuj
Coś ze sterowaniem jest nie tak, odpaliłem nową misję Bałtyk_en57 - ciężarówka przejechała przez szlaban i utknęła tam, zablokowała ruch, misja nieprzejezdna dzięki temu. Na exe 481 działa (chociaż kierpoć się wiesza).

Ta ciezarowka co tam utkwila specjalnie mnie nie dziwi, na Baltyku w ogole sa jakies siupy z polaczeniami drog (np. samochody zderzaja sie na skrzyzowaniu i pojawiaja jakies 100 m. dalej, na drugim koncu odcinka szosy) Chociaz chyba wylazly tam jakies nowe rzeczy w miedzyczasie, przyjrze sie.

Co do dzwiekow to trudno mi cos powiedziec, na testach EN57 slysze tylko kompresor i cykacz, czyli wydaje sie w porzadku. Jest na poczatku jakis krotki szum (i AI korzysta z bledu i wlacza odluzniacz ktory normalnie w EN nie dziala) ale nie wiem czy tak ma byc, az tak sie na pociagach nie znam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 05 Lutego 2017, 18:04:16
Z tymi cudzysłowami próbowałem już kiedyś tak, jak mówisz, ale potem parser yaml-owski nie wie co zrobić z resztą parametrów.  Mam pewien pomysł, ale sprawdzę go chyba dopiero jutro.
A jeżeli chodzi o komentarze, to można by było zrobić (a może już jest, proszę o link) plik, w którym jest cały opis pliku mmd ze wszystkimi parametrami i ich przeznaczeniem, a te komentarze usunąć, bo jest dużo niepotrzebnych. Natomiast nie wiem co z parametrami odkomentowanymi.
Przesyłam specyfikację YAML 1.2 może się do czegoś przyda.
Wyglada na to, ze YAML jest tak skonstruowany, ze jednak nieco gryzie sie z tym, jak symulator ma zorganizowane pliki. Z tego co widze, mozliwosci jest kilka:

1. brak komentarzy w plikach .mmd -- najmniej pracy, ale brak komentarzy

2. zgrupowanie wszystkich parametrow dzwieku w jeden token przy uzyciu cudzyslowow, i zmiana w kodzie symulatora, zeby to wewnetrznie rozbijac na poszczegolne parametry. Z jednej strony ma to jakas zalete (troche lepsza kontrola nad parametrami dla dzwieku), z drugiej strony wymaga to poprawienia wszystkich istniejacych .mmd

3. podawanie parametrow w formie
foo:
 - bar.wav
 - 50
 - 75
itp. i zmiana w kodzie parsera, zeby ignorowal ciagi typu " - " Rowniez wymaga zmian we wszystkich plikach .mmd, i jest szansa ze przy okazji skoliduje z czyms gdzie indziej, czego na razie nie jestem w stanie przewidziec.

4. zrobienie "tego co trzeba", tzn. zapis plikow .mmd w pelnym formacie YAML, i dla wygody podpiecie parsera ktory to obsluguje, jako alternatywy dla biezacego kodu, ktory moze nadal obslugiwac stary format .mmd, ten bez identyfikatora YAML na poczatku. Jako ze jest to najbardziej pracochlonne rozwiazanie, wstrzymalbym sie z tym do czasu, gdy mamy obiekty symulatora przerobione na nowy standard (po tym jak w ogole powstanie nowy standard) zeby nie uczyc parsera dwa razy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 05 Lutego 2017, 18:28:05
Zasadniczo nowe exe wygląda coraz lepiej, ale jeszcze trochę poprawek się przyda:
- podwójne EN57 faktycznie mi zadziałało, ale dla odmiany AI popsuło się w jednej z EP09 - prawdopodobnie jest to błąd, o którym wspominałeś (jakaś nieinicjowana zmienna), bo poprzednim razem ten pociąg działał - objawy te same: pantograf w górze, rozkład ma nadany, końcówki się świecą, ale oświetlenia czoła nie ma i nie reaguje na podawane semafory
- wygląda na to, że SN61 utracił hamulce. Jeździć jeździ, ale zatrzymuje się dopiero, jak mu rozpędu braknie :)
- symulator pod F1 wyświetla godzinę przyjazdu do kolejnej stacji bez zer tj. np. 14:05 to 14:5; w widoku rozkładu pod F3 jest normalnie
- faktycznie model kabiny jakoś dziwnie skacze w czasie jazdy

Ale tak poza tymi rzeczami to wygląda na to, że jest naprawdę spoko. Puściłem na jednej ze swoich misji na nowym Całkowie AI, nieco dziwnie kręci nastawnikiem i hamulcami, ale w sumie jedzie i nawet się bardzo nie spóźnia. Reszta pociągów też jeździ, zmienia czoła bez problemów, rozkłady są im nadawane i się przewijają, obloty i podczepianie się loków też działa.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 05 Lutego 2017, 22:44:31
Ja tylko zasugeruje wyłączenie bujania do czasu, aż będzie to można ogarnąć inaczej (opis w innym wątku). Na długim odcinku Kaliskiej można ocipieć od skakania kabiny. Dzięki za numerowanie kompilacji. Inne pojazdy i scenerie następnym razem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: art72 w 06 Lutego 2017, 00:29:23
Przejechałem dziewiątką w obie strony Drawinowo. Dwukrotnie - raz wczoraj i raz dziś. Bez żadnych problemów.

Jedyny zgrzyt to brak potrzebnej biblioteki glew32.dll.

Sceneria wczytuje się błyskawicznie. W dodatku bardzo podoba mi się wyświetlanie zainicjowanych zmiennych - znak, że wszystko jest pod kontrolą.

Potwierdzam irytujące buczenie zaraz po uruchomieniu/pokazaniu kabiny. Na szczęście szybko można się go pozbyć wyłącznikiem czuwaka.

Na moje niefachowe oko wszystkie wskaźniki działają prawidłowo: mierniki natężenia/napięcia, manometry, hasler, diody po lewej stronie woltomierzy, kontrolki itd.

Nie jestem tylko pewien, czy kran hamulca po wciśnięciu klawisza "4" ustawia się na tej samej pozycji, co w poprzednim exeku. Jutro to sprawdzę.

Z widocznych błędów potwierdzam brak polskich znaków diakrytycznych w rozkładzie jazdy i treści wyświetlanych komunikatów radiowych.

Sam rozkład jest identyczny dla drogi "tam" i "z powrotem".

Podczas wczorajszej jazdy powrotnej spotkała mnie miła niespodzianka. Otóż przed wjazdem na stację w Grabówku zostałem (po raz pierwszy) skierowany na inny peron. I semafory po drodze (bodajże dwa) pokazywały odpowiednie sygnały.

[za to na przeciwnym torze, pod semaforem wjazdowym stały... 3 towary, jeden za drugim. Normalnie kolejowy traffic jam :D ]

Nie ukrywam - było to przyjemne urozmaicenie jazdy trasą znaną niemal na pamięć.

Niestety, dziś to już się nie powtórzyło.

Gdyby komuś chciało się dociec, jakie czynniki spowodowały wspomniane odchylenie - załączyłem skompresowany log z wczorajszej służby.

@firleju (i @tmj też) odwaliłeś kawał świetnej, potrzebnej i żmudnej (jak pchanie łańcucha pod górę) roboty.

Podłączam się do propozycji któregoś z przedmówców: możemy spokojnie zacząć zrzutkę na browar, szkocką, czy co tam zechcesz. Podaj tylko numer konta (ewentualnie numer, na który należy wysyłać SMSy o treści "firleju" ;)) coby przelew mógł się dokonać.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 06 Lutego 2017, 00:51:21
Po przeczesaniu zrodel szczotka znalazla sie jedna przyczyna bledu hamulca lokalnego. Pomoglo w przypadku EU i chyba takze innych, ale SN61 pozostaje odporny (w SN dziala hamulec glowny, ale AI go nie uzywa, no i lokalny tez powinien chodzic, wiec cos tam jeszcze jest skopane)

Skorygowalem przy okazji troche obsluge drzwi w skladach AI; powinny teraz pozostawac otwarte na przystanku az do odjazdu, bez wachlowania co chwila, gdy mechanik sie budzi.

Rzucanie kamera zredukowane do bardziej sensownych rozmiarow. Poczatkowo bylo dopasowane do EU07, ktora ma dosc lagodnie ustawione paramtery w konfiguracji, wiec w pozostalych pudlach dzialo sie, ze hej.

Jesli brak glew.dll jest problemem to w przyszlosci mozna by skompilowac go w jedna calosc z .exe, ale plik bedzie tak ze dwa razy wiekszy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 06 Lutego 2017, 16:09:40
Exe po konwersji ma kłopot z rysowaniem niektórych obiektów. Złapałem takie coś jak w załączniku. Prawidłowy screen zrobiony na exe 483 z paczki.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 06 Lutego 2017, 16:14:59
W ktorej scenerii wystepuje to miejsce? Nie bardzo mi sie widzi szukanie na slepo :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 06 Lutego 2017, 16:23:04
Tylko czym to się technicznie różni od drzewa? Node triangle z alfą.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 06 Lutego 2017, 16:32:35
Screeny z błędem zrobiłem w nocy, późno już było. To są domki na Kaliskiej po lewej od torów przed Lublinkiem. Miałem też kilka tak narysowanych drzew, ale nie wszystkie. Kilometraż widać na screenie (po 6 kilometrach). Exe z 170205. Jednak jeszcze sprawdzę na tej nowszej kompilacji. Wcześniej bawiłem się klawiszami F5, F6, F7 i F8, one przełączają też widok teksturowania, może nie wróciło jak trzeba. Sprawdzam teraz 170206, może to jednorazowy wybryk. Wczytywanie Kaliskiej skróciło się o 300 sekund.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 06 Lutego 2017, 16:44:13
U mnie wyglada jak trzeba, chociaz nie sprawdzilem tez przy wlaczonym VBO, zobacze za chwile. Moze to bylo po zabawie klawiszami funkcyjnymi? Ten drugi screen wyglada jakby wlaczony byl tryb wireframe albo cos.

edit: VBO rysuje tak samo, znaczy sie widac plot na obu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 06 Lutego 2017, 16:47:48
Witam.
 Wczoraj w ramach testu uruchomiłem na Exe++170205 Kaliską z towarem Sieradz - Ostrów ( ET22+ Gags). Zaobserwowałem że lok wpada bardzo łatwo w poślizg podczas rozruchu. A co najważniejsze ani piasecznica, ani hamulec przeciwpoślizgowy nie powodują żadnej reakcji. Ba, nawet zjechanie nastawnikiem do zera nic nie daje. Pomaga dopiero zdecydowane hamowanie hamulcem zasadniczym. Czy zauważył ktoś z kolegów podobny problem? Dzisiaj ustawie ten sam skład na TD i sprawdzę czy jest on powtarzalny.
  Czy hamulce nie są zbyt słabe w tej wersji? Nawet przy nastawie P w całym skladzie pociągu, reakcja jest dużo słabsza, niż na oficjalnych wersjach exe. Zauważyłem rownież brak wskazań woltomierza NN.
O bujaniu kamery, i hamulcu pomocniczym była już mowa.
Generalnie jakoś ładniej wygląda grafika na tym exeku. Scenerie ładują się o wiele szybciej. Pociągi prowadzone przez AI jadą normalnie, reagując na semafory, W4 jak trzeba.
Pozdrawiam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 06 Lutego 2017, 17:07:20
Witam.
 Wczoraj w ramach testu uruchomiłem na Exe++170205 Kaliską z towarem Sieradz - Ostrów ( ET22+ Gags). Zaobserwowałem że lok wpada bardzo łatwo w poślizg podczas rozruchu. A co najważniejsze ani piasecznica, ani hamulec przeciwpoślizgowy nie powodują żadnej reakcji. Ba, nawet zjechanie nastawnikiem do zera nic nie daje. Pomaga dopiero zdecydowane hamowanie hamulcem zasadniczym. Czy zauważył ktoś z kolegów podobny problem? Dzisiaj ustawie ten sam skład na TD i sprawdzę czy jest on powtarzalny.
Coz moze byc nie tak z obsluga tego konkretnego wariantu ET22. Postawilem go na TD i nawet gdy stoi nieruchomo rzuca sie w nim kamera, co sie normalnie nie powinno zdarzac. I faktycznie, slizga sie. Zobaczymy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 06 Lutego 2017, 17:12:43
Na 170206 rzucanie Kabiną (nie kamerą) mam znośne, co nie znaczy że jest dobrze. Wyświetlanie drzew i płotów wygląda na jednorazowy wybryk, ale będę to miał na uwadze. Na składach osobowych natomiast nie potwierdzę ślizgania, bo nie udało mi się do tego doprowadzić. O ile pamiętam powinien pomóc hamulec przeciwpoślizgowy, na numerycznej klawisz 0. num enter. Zero to nagłe. | @Stele
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 06 Lutego 2017, 21:12:17
Jesli brak glew.dll jest problemem to w przyszlosci mozna by skompilowac go w jedna calosc z .exe, ale plik bedzie tak ze dwa razy wiekszy.
Jak wersja tego pliku się nie zmienia z kolejnymi exe-kami, to po co? Powinien być jak najlżejszy, to będą lżejsze aktualizacje.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 06 Lutego 2017, 23:03:23
Na 170206 rzucanie Kabiną (nie kamerą) mam znośne, co nie znaczy że jest dobrze. Wyświetlanie drzew i płotów wygląda na jednorazowy wybryk, ale będę to miał na uwadze. Na składach osobowych natomiast nie potwierdzę ślizgania, bo nie udało mi się do tego doprowadzić. O ile pamiętam powinien pomóc hamulec przeciwpoślizgowy, na numerycznej klawisz 0. num enter. Zero to nagłe. | @Stele
Witam.
Oczywiście chodzi o kabinę, a nie kamerę. Dzięki za poprawienie. Co do poślizgu, sprawdziłem na TD z tym samym składem- taka sama sytuacja. Brak przyczepności, brak reakcji na sypanie piasku, w bardzo niewielkim stopniu pomaga hamulec przeciwpoślizgowy. Po zejściu nastawnikiem do zera, zestawy kołowe nadal rolują okresowo. Hasler wskazuje poprzednią prędkość. Jak dla mnie ET22 jest na tej wersji EXE ciężka do prowadzenia z pociągiem towarowym. Niby działa, ale nie tak jak powinna.
Pozdrawiam.
Edit:
To samo dzieje się podczas jazdy siódemką na TD domyślnym składem ( Exe C++ 170206). Jak dać jej ok 600A to zaczyna rolować i przestać nie chce:-) Jakby niewidzialna ręka lała litrami olej na szyny, a silniki trakcyjne zasilała energia kosmosu ( nastawnik na zero). Identycznie jak w ET22 poprzednio.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 06 Lutego 2017, 23:46:29
Jadę w tej chwili kiblem po kaliskiej, więc nie sprawdzę tego. Jednak dziwi mnie, po co dawać 600A przy rozruchu? Jeśli maszyny nie wychodzą z rolowania, to pewnie jest jakiś bug. Do tej pory jazdy, które zaliczyłem na ET22 i EU07 na C++, nie udało mi się złapać poślizgu. Po za tym, ja Ciebie nie poprawiałem z tą kamerą, albo źle mnie zrozumiałeś. W tej chwili okropnie trzęsie kabiną, a moim zdaniem ruchy powinna wykonywać kamera jako bezwładny element w kabinie, tak jak nasza głowa z oczami. Zakres amplitudy tych drgań powinien się zawierać w kilku centymetrach i większy powinien być w poziomie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 07 Lutego 2017, 00:57:48
Jeśli maszyny nie wychodzą z rolowania, to pewnie jest jakiś bug.
Zdecydowanie tak, i wyglada na to ze jest to dosc uniwersalne, ale ciezko w tym momencie znalezc przyczyne. Tzn mam potencjalnego kandydata, ale zrekonstruowanie go troche potrwa, no i nie ma gwarancji ze to jest akurat to.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 07 Lutego 2017, 01:07:43
W pliku ini i także w rainsted jest możliwość zaznaczenia uruchamiania elektryków nawet jeśli nie ma drutu jezdnego.
Na C++ ta funkcja nie działa. Na Kaliskiej są pętle startowe (tory) z których podstawiają się składy. Nie można takiego składu ruszyć nawet jeśli odhaczono "Napięcie tylko pod trakcją". Pętle te nie mają powieszonej sieci. Póki co to poważny problem. Może też powodować przypadkowe utknięcia składów w miejscach gdzie sieć jest marnie dopasowana, a skład musiał się zatrzymać.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: MaciejM w 07 Lutego 2017, 12:30:52
Nie działa przestawianie pozycji rozjazdów (T/t), chociażby w rozjazdach @Benka, innych nie sprawdzałem. Potwierdzam brak działania elektrowozów / EZT-ów na torze bez sieci przy wyłączonej w/w funkcji. Potwierdzam błąd związany z poślizgiem - objawia się nie tylko przy ruszaniu, ale też przy hamowaniu, gdzie osie trą po szynie i możemy stracić hamowanie. Smuga mi działa o każdej porze dnia i nocy, to samo podświetlanie okien w budynkach, latarń itd. Kamera buja, aż miło. Może aż za bardzo buja.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 07 Lutego 2017, 17:16:35
Dziś rano próbowałem pojechać Całkowo SN-61, i okazało się, że nie działa klawisz W (nie odpala zdarzenia), więc siłą rzeczy nie szło przejechać tej misji. I druga sprawa, chciałem zatrzymać szynobus hamulcem pomocniczym i tu ciekawostka - kran hamulca na ekranie się przekręcił, ale nie zadziałał. W ogóle brak hamowania.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: matek123 w 07 Lutego 2017, 17:46:00
Czyli nie działają eventlaunchery wyzwalane klawiszem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 07 Lutego 2017, 22:00:10
Uzupelnilem parser plikow .fiz o brakujace elementy, pozytywny efekty ktore dalo sie zaobserwowac (moga byc tez takie, ktorych nie zauwazylem) to przywrocenie mozliwosci jazdy elektrowozami bez drutu przy zaznaczonej opcji, i dzialajacy znowu woltomierz. Niestety nie pomoglo to z poslizgiem, na co mialem nadzieje, czyli problem jest gdzie indziej.
Poprawiony jest tez blad z rozjezdzajacym sie rozkladem przy braku podanego wyposazenia stacji.

edit: znalazlem ten cholerny poslizg :d  dla zainteresowanych, w Pascalowym oryginale bylo:
    if Max0R(Abs(FTrain),Fb)>TotalMassxg*Adhesive(RunningTrack.friction) then    {poslizg}
     SlippingWheels:=true;
    if SlippingWheels then
      begin
     nrot:=ComputeRotatingWheel ( ... // etc

a w tlumaczeniu:
    if (Max0R(abs(FTrain), Fb) > TotalMassxg * Adhesive(RunningTrack.friction)) // poslizg
    {
      SlippingWheels = true;
      nrot = ComputeRotatingWheel( ... // etc

i w rezultacie w wersji c++ po wpadnieciu w poslizg predkosc obrotowa kol byla przeliczana tylko raz, a potem juz zawsze krecily sie ze stala predkoscia bez szans na zatrzymanie. Teraz jest juz jak trzeba :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 08 Lutego 2017, 22:53:12
Elektryki wstały bez drutu. Lubię to.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: MaciejM w 08 Lutego 2017, 23:07:50
Siadło filtrowanie. Tutaj przykładowo tektura o nazwie #nazwa.tga nie powinna się rozmywać. Elektryki bez sieci działają ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 08 Lutego 2017, 23:28:02
Siadło filtrowanie. Tutaj przykładowo tektura o nazwie #nazwa.tga nie powinna się rozmywać.
Przyznam bez bicia ze nie siadlo, tylko jest specjalnie wylaczone bo do takich rzeczy to jest texture_bias, a nie zmuszanie karty do mordowania pixeli ;)  Roznica dosc imo ewidentna na dolaczonym screenie, chociaz ten akurat fragment kodu jeszcze nie jest wlaczony do wydanego .exe
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 09 Lutego 2017, 00:13:53
Witam.
Na nowej wersji (exe++ 170208) rolowanie ustało, lokomotywy wykazują normalną przyczepność. Bujanie jest na dość przyjemnym poziomie. Ażeby nie było tak słodko, hamulec zespolony działa coś nie tak. Testuje exe na Kaliskiej. AI prowadząc ET22-293 plus puste węglarki w Sędzicach przerżnęło S1 wyjeżdżając częściowo na szlak. Sprawdziłem, i okazało się że przy ciśnieniu 2,1 atm na wagonach, one prawie nie hamują. Dopiero przestawienie kranu na pełne hamowanie służbowe daje jakiś skutek. Może problem z zależnością hamowania od masy ładunku?
Pozdrawiam.
 Edit: Przetestowałem jeszcze inaczej. Zahamowałem skład hamulcem zespolonym, wyluzowałem samą lokomotywę i... ruszyłem bez problemu ze sznurkiem węglarek na haku ( zahamowanych).
 Wniosek: wagony nie hamują, pomimo wzrostu ciśnienia w cylindrach hamulcowych.
  Jeszcze jedno, w jadącym z naprzeciwka składzie światła nagle "przygasają" w odległości ok 400m od nas. Jakby maszynista go prowadzący, zgasił reflektory.
Pozdrawiam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 09 Lutego 2017, 14:51:55
Glupie pytanie, ale jak wlasciwie sa organizowane (zakladam ze na poziomie plikow scenerii) takie rzeczy jak przelaczanie zwrotnic przez T, albo eventy z klawisza W? Bo domyslnie te klawisze robia zupelnie cos innego, i jesli to mozliwe przydalby sie jakis punkt zaczepienia, zanim zaczne przegrzebywac cale .exe...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 09 Lutego 2017, 14:54:19
Jest to typ eventlauchera wyzwalany klawiszem w danym promieniu.
http://rainsted.com/pl/Symulator/MaSzyna/Scenery.doc#node_.E2.80.A6_eventlauncher
Zwrotnice hardkodowane kiedyś były, ale zostały usunięte dawno temu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 09 Lutego 2017, 15:37:04
Dzieki, znalazlo sie. Tradycyjnie juz zrodlem byla roznica w kodowaniu stringow w Borlandzie (gdzie znaki numerowane sa od 1) i w stl (gdzie numerowane sa od 0). W rezultacie eventy nie dostawaly swojego klawisza sterujacego. Teraz jest ok, bedzie w nastepnej wersji .exe
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 09 Lutego 2017, 15:37:27
Witam ponownie.
Nie dam spokoju z tymi hamulcami. Sprawdziłem teraz na TD, wagony pasażerskie hamują normalnie, natomiast towarowe wcale, niezależnie od lokomotywy. Moim zdaniem ma to związek z nastawą hamulca w wagonach G, P, R. Na R hamuje normalnie. Sprawdzał ktoś ten błąd? Exe C++ 170208.
Pozdrawiam.
Edit: Można by jeszcze sprawdzić co da przestawienie hamulca w kabinie. Zaraz przetestuje.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 09 Lutego 2017, 16:04:34
To by odpowiadało temu, że zaobserwowałem przerżnięcie składów towarowych na kaliskiej przez S1. Sprawdzę czy efekt powtórzę na zwykłym exe, jeśli pójdzie dobrze, to z hamulcami wagonów jest słabo. ET42 urwało mi się od składu, ale tu nie mam jakiegoś konkretnego punktu zaczepienia.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 09 Lutego 2017, 16:37:57
Witam.
Sprawdziłem teraz ponownie na TD. Przestawienie hamulca na R w lokomotywie, ani na P w wagonach nic nie dało. Zdecydowanie z hamulcami w towarowych jest problem. Nastawa R w pasażerskich działa, G oraz P w towarowych już nie. Skład nie hamuje wcale.
Edit: Sprawdziłem na oficjalnym exe z paczki. Wagony towarowe w stanie zahamowanym trzymają jak przyspawane.
Pozdrawiam.
Ps. Wczoraj na Kaliskiej u mnie też urwało byka od talbotów w Błaszkach. Nie wiem czemu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 09 Lutego 2017, 17:06:07
Czy moglbys jeszcze sprawdzic, czy po przestawieniu wagonow pasazerskich z R na cos innego dalej zachowuja sie normalnie, czy ida w maliny?

Ze z hamulcami jest cos na rzeczy bylo raczej pewne od momentu gdy SN61 jezdzil sobie, kompletnie je ignorujac, ale ten system jest tak rozlegly, ze dobrze byloby znalezc punkt startu. Na chwile obecna nie wiem czy sa to nastawy, czy tez moze blad siedzi w kodzie jakiegos konkretnego typu/rodziny hamulcow.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 09 Lutego 2017, 17:15:27
 Chciałem to właśnie sprawdzić przestawiając z R na P, tyle że nie mogę za nic zmienić nastawy z R na coś innego. Kombinacja klawiszy dla towarowych nie powoduje żadnej reakcji w pasażerskich. Bo byłby wtedy jak piszesz, punkt zaczepienia czego szukać. Zna ktoś sposób? Nawet z poziomu startera się nie udaje.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 09 Lutego 2017, 17:20:56
Musisz chyba zmienic wpis dla wagonu w pliku .fiz -- np dla 1xxa jest:
Cntrl. BrakeSystem=Pneumatic LocalBrake=ManualBrake BrakeDelays=R ASB=Yes MCPN=1
co, o ile sie nie myle oznacza, ze wagon przyjmie tylko nastawienie R.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 09 Lutego 2017, 17:36:48
A o tym nie pomyślałem. Zmieniłem nastawę dla wagonu 111A na P, a następnie G. I niestety to zły trop, są zahamowane przy spadku ciśnienia w PG jak trzeba. Szkoda...
Edit: W ramach eksperymentu dodałem linijkę " ASB=Yes " w nastawie losowego wagonu towarowego ( 412z), która występuje w fiz. 111A, niestety dalej to samo.
A może podmienić zawory rozrządcze? - " tonący brzytwy się chwyta"
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 09 Lutego 2017, 17:55:47
Jesli udalo sie to wykluczyc, to akurat nie jest zla wiadomosc. W takim razie potencjalnym kandydatem bylyby hamulce z rodziny ESt3 (a konkretnie TNESt3) bo wystepuje on chyba we wszystkich problematycznych wagonach... chociaz takze chyba w bhp_v1 ktore zdaje sie nie jezdza normalnie? Warto by je moze tez sprawdzic.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 09 Lutego 2017, 17:58:12
Jeździłem z wagonami BHP, nie miałem problemów z hamulcami. Ale niech jeszcze ktoś to sprawdzi.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 09 Lutego 2017, 18:00:40
Bingo. Podmieniłem zawory rozrządcze pomiędzy 111A i 412Z wagony towarowe teraz hamują. Ale tylko gdy wkleiłem cały wpis hamulca, gdy podmieniony sam zawór-to samo:-(
Czyli to: Brake: BrakeValve=ESt3 Size=16 MBF=144 MaxBP=3.8 BCN=1 BCR=0.2032 BCD=0.14 BCMlo=3.43 BCMHi=12.00 NBpA=4 BM=P10-Bg BCS=2.7 BSA=16.00 BVV=88 BRE=0.8Na to:Brake: BrakeValve=ESt4 Size=200 NBpA=4 MBF=90 MaxBP=4.0 BCN=2 BCR=0.1778 BCD=0.150 BCM=8.44 BCS=1.4 BSA=8.0 BM=P10-Bgu BVV=200
BRE=0.87
Bipy zaraz sprawdzę.
  No i Bipa niestety hamuje jak trzeba. Ja już głupi jestem...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 09 Lutego 2017, 18:36:13
Hmm a robi jakas roznice jak sie wymieni BhP BrakeValve z ESt3AL2 na zwykle Est3 ?

(w kodzie powoduje to wymiane jednego z elementow na zwykla rure. ale w pascalowym oryginale jest to samo, wiec nie wiem czy ma to jakies znaczenie. Tutaj by sie musial przyjrzec ktos, kto sie zna jak hamulce w ogole dzialaja)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 09 Lutego 2017, 18:57:12
Na hamulcach jak nikt zna tylko królik. Można by powiedzieć, że spędził nad nimi pod nimi (Stele ;)) 1/3 życia. @YouBy przybywaj!
Grześ, wybacz mi;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: youBy w 09 Lutego 2017, 21:52:27
Tak, wagony 111A mają tylko nastawienie R. W 120A (Bh) powinny być dostępne obie nastawy przy pozostałych parametrach właściwie takich samych.

Jeśli ciśnienie w cylindrach rośnie prawidłowo, to problemu należy szukać w układzie siłowym (między cylindrem a klockami). Stawiam na to, że problemem jest określanie właściwej wartości P2FTrans. Wagony towarowe proste mają dwie wartości BCM (zmieniane).
Przy okazji - czy coś się zmienia po zmianie nastawy próżny/ładowny (h/H w widoku freefly)?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 09 Lutego 2017, 22:05:03
Na C++ 170208 dwa razy z rzędu wywaliło mnie do windowsa z logiem kończącym się jak w załączniku. Zrobiłem screen komunikatu, ale się nie zapisał, więc dodam tylko, że czegoś program nie znalazł po czym się zwiesił i zamknął. Były to dwa różne scenariusze. Skład ET42+ beczki, hamowanie miałem normalne, to skład który wcześniej urwał się od loka i zablokował ukończenie jazdy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 09 Lutego 2017, 22:19:30
Jeśli ciśnienie w cylindrach rośnie prawidłowo, to problemu należy szukać w układzie siłowym (między cylindrem a klockami). Stawiam na to, że problemem jest określanie właściwej wartości P2FTrans. Wagony towarowe proste mają dwie wartości BCM (zmieniane).
Z tego co moge znalezc, funkcja BrakeForce zwraca wartosc 0 poniewaz wyliczona wartosc u jest mnozona przez K, ktore w przypadku ManualBrake ma wartosc 0, poniewaz ManualBrakePos ma wartosc 0, i nie wyglada zeby cokolwiek ja zmienialo. Z tym, ze Bhp ktore rowniez maja hamulec lokalny ManualBrake jakos hamuja, wiec chyba dzieje sie tutaj cos jeszcze... no i akurat ten kod jest identyczny z tym co jest w Pascalu, wiec za bardzo to nie pomaga. Trzeba grzebac dalej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 09 Lutego 2017, 22:21:19
Na C++ 170208 dwa razy z rzędu wywaliło mnie do windowsa z logiem kończącym się jak w załączniku. Zrobiłem screen komunikatu, ale się nie zapisał, więc dodam tylko, że czegoś program nie znalazł po czym się zwiesił i zamknął.
Jesli to nie problem, mozesz sprawdzic czy w katalogu symulatora znajduje sie plik z eu07 z 'crashdump' w nazwie, i jesli jest, to czy moglbys go tutaj dolaczyc?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 09 Lutego 2017, 22:31:58
W katalogu głównym nie znalazłem takiego pliku, odpaliłem jeszcze raz ten sam scenariusz z ET42, chwilę jeszcze mam do odjazdu. Za każdym razem jest podobny odcinek czasu od uruchomienia scenerii do wysypu. Wyłączyłem w konsoli zapis jakichkolwiek logów, za to przygotowałem się na zarejestrowanie komunikatu na ekranie. W momencie jego pojawienia niestety printscreen nie zadziała.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 09 Lutego 2017, 22:47:10
W katalogu głównym nie znalazłem takiego pliku
Hmm sprawdzilem na szybko u siebie, i tutaj crashdump dziala normalnie... nie trzymasz chyba symulatora w podkatalogu Program Files, albo cos takiego?

Czy to jest na Kaliskiej, czy gdzie indziej? W ostatecznosci moge sprobowac odpalic u siebie, moze tez mi wyleci.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 09 Lutego 2017, 23:09:20
Maszyna trzymam w katalogu z zamienioną nazwą EU07, na "czysta paczka". Katalog jest na dysku C winXP. Wyłączyłem zapis wszelkich logów i zamknąłem konsolę, moment wysypu dawno minąłem. Wygląda, że zapisywanie ma z tym związek. Zamienię, ale to już jutro, nazwę katalogu na EU07 i odpalę jeszcze raz, ale z włączonymi zapisami logów i plików. Czy nazwa katalogu głównego z plikami maszyny jest w tym przypadku krytyczna? Niestety nie zauważyłem wcześniej, hamulce w beczkach są żadne, sam nie wiem jak to przeoczyłem. Natomiast sprawdziłem w trybie freefly, że w cylindrach jest ciśnienie. Jadę dokąd się nie wywalę z braku hamulca...
Tak, Kaliska ET42-024.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 09 Lutego 2017, 23:14:51
Jeśli ciśnienie w cylindrach rośnie prawidłowo, to problemu należy szukać w układzie siłowym (między cylindrem a klockami).
Tak ciśnienie rośnie normalnie do nominalnej wartości. Ale jest jeszcze inna dziwna rzecz. Wagony momentalnie luzują, tak jakby miały nastawę R, mają przecież G. Widać to doskonale po naciśnięciu F2 i przeleceniu nad składem. Ostatnio zresztą to nawet nim nie ruszam w celu sprawdzenia, gdyż wystarczy uruchomić lokomotywę i nacisnąć num6. Potem nastawnik do przodu i już wiadomo czy jest dobrze czy nie. Taki przykład: EU07 z załadowanymi podkładami 24 platformami sgs, masa ładunku ustawiona na 20 ton. Ciśnienie w cylindrach hamulcowych ok 2 atm, a pociąg rusza bez zająknięcia, po wyluzowaniu samej lokomotywy.
Cytuj
Przy okazji - czy coś się zmienia po zmianie nastawy próżny/ładowny (h/H w widoku freefly)?
Tego nie sprawdzałem.

  @Tmj, czy przypadkiem każdy typ zaworu nie jest w exe osobno opisany. Bo bipa ma jednak trochę inny typ-ESt3AL2. Może gdzieś jakaś literówka się wkradła przy tym nieszczęsnym ESt3?
Pozdrawiam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 09 Lutego 2017, 23:24:51
A ja w sprawie wysypu. Tym razem złapałem komunikat w załączniku, logu nie mam bo wyłączyłem opcję.Kurcze, czy tylko ja mam taki wysyp? Jutro sprawdzę na exe z 6 lutego, nie miałem tam takich zapaści.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 09 Lutego 2017, 23:40:36
Nazwa katalogu raczej nie ma znaczenia, o Program Files zapytalem bo na nowszych wersjach Windows zapis w tym katalogu jest wylaczony, ale wtedy nie dzialalo by tez tworzenie logow, wiec nie wiem czemu nie wyprodukowal crashdump.

Jesli wylaczenie logu pomoglo, to najprawdopodobniej wywala sie, gdy probuje zapisac dane jakiegos eventu albo czegos, ktory w rzeczywistosci nie istnieje. Jeden taki blad wycialem wczesniej, ale widac jest wiecej.

Co do hamulcow, znalazlem (kolejnego) potencjalnego kandydata -- IncBrakeMult() nie zwieksza ustawienia BrakeCylMult[0] poniewaz zalezy to (miedzy innymi) od wartosci parametru MaxBPMass, ktory jest domyslnie ustawiony na 1 * 1000, a test oczekuje wartosci nie wiekszej niz 2. @youBy, czy to mnozenie ma tam byc, czy jest to jakas pomylka? Po usunieciu mnoznika IncBrakeMult() zalacza sie, i wagony towarowe hamuja jak trzeba, ale nie wiem czy to nie psuje czegos gdzie indziej..?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 09 Lutego 2017, 23:46:28
Tylko że, do poprzednich wersji C++ nie miałem wysypów, dla mnie to nowa sytuacja. Wysypało mnie, mimo wyłączenia komunikatów, tyle że sporo później. Nic nie dodawałem do paczki, prócz następnego exe. Jest dziś zbyt późno aby jeszcze raz inicjować przejazd, ale jutro to zrobię. No i nikt inny nie zgłasza problemu, ten komunikat coś wyjaśnia?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 10 Lutego 2017, 00:00:37
Nie bardzo, tzn wyjasnia, dlaczego sie wysypal (nie znalazl potrzebnej funkcji) ale nie wyjasnia dlaczego nagle zaczeloby mu tej funkcji brakowac. Sprobuj zainstalowac ponownie VC2013 runtime ( ze strony Microsoftu, https://www.microsoft.com/en-us/download/details.aspx?id=40784 ) ale szczerze mowiac nie wiem, czy to pomoze.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 10 Lutego 2017, 01:38:21
Witam ponownie.
Jeszcze taka drobnostka, która mnie osobiście razi. Gdy zbliża się skład z naprzeciwka jego czoło na początku wygląda normalnie. Czyli widoczne z oddali trzy wyraźne punkty świetlne ( pierwszy screen), a po paru metrach wszystko "gaśnie" i wygląda jak na drugim obrazku.
 I kolejna sprawa związana z oświetleniem. Czynne w danej chwili komory semaforów jak dla mnie są zbyt słabo widoczne. Trzeba mocno się wpatrzeć, aby dostrzec co semafor wyświetla w danej chwili.
  Wiem że są dużo poważniejsze problemy obecnie, ale zgłaszam jak coś znajdę:-)
 
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 10 Lutego 2017, 02:25:06
Doinstalowalem biblioteki do systemu i pomoglo. Zaznaczylem zapis wszystkich logow i nie wysypalo. Co prawda nie ukonczylem calej trasy ze wzgledu na hamulce w towarach, ktore nie daja rady zatrzymac sie przed semaforem  z S1. Potwierdzam znikanie trojkata swiatel, z semaforami nie zauwazylem, ale mialem inne klopoty to moglo mi uciec. A mialem spac...
Do znalezienia i naprawy hamulca w towarach, nie ma co meczyc przejezdnosci.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 10 Lutego 2017, 03:46:04
Na ile moge powiedziec po pobieznych testach, to usuniecie mnoznika przy ladowaniu parametru MaxBPMass powoduje poprawne startowe ustawianie hamulcow w zaleznosci od ladunku, i sklady towarowe hamuja tak, jak oczekuje tego AI (z dokladnoscia 10-15m do wskaznika) a przy tym nie widac jakichs negatywnych skutkow ubocznych dla skladow osobowych. Nie wiem, czy ten sposob rozwiazania sprawy jest koszerny, ale dopoki nie wypowiedza sie eksperci, idzie to testow.

W uaktualnieniu poprawione jest tez przypisywanie klawiszy do eventow, jak rowniez obsluga ewentualnych duplikatow.

Oprocz tego zmieniona jest nieco obsluga tekstur, na sprzecie z openGL 1.4 lub nowszym. Od razu mowie ze jakiegos specjalnego szalu nie ma, niemniej jest chyba nieco lepiej, a w kazdym razie wyrazniej :)

Jesli chodzi o swiatla, to mozliwe, ze po przeniesieniu na c++ ogolna wydajnosc podniosla sie na tyle, ze silnik wlacza teraz wyswietlanie tekstur zamiast punktow swietlnych nieco wczesniej niz poprzednio, co paradoksalnie redukuje ich widocznosc. Ale sprobuje sie przyjrzec.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 10 Lutego 2017, 09:23:39
Punkty świetlne powinny być widoczne zgodnie z ustawieniem w t3d, jak wszystkie inne obiekty. Nie było to hardkodowane i nigdy nie było ustawiane na tak wielką wartość. Raczej na kilka-kilkanaście metrów, gdy wyraźnie widać już teksturę i ten pikselik mógłby razić.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 10 Lutego 2017, 13:43:36
Wstepnie po jednym przejezdzie powiem, ze sklady towarowe zaczely hamowac jak trzeba. Przejechalem EU07-344 az do Zdunskiej Woli i tu zrobil sie problem. Podkusilo mnie przejac mijany sklad ET42-024, wcisnalem F5. Jest jakis problem zwiazany z urywaniem skladu od loka. Uruchomienie autopilota powoduje natychmiastowe hamowanie, ponowne ruszenie skutkuje rozpieciem sprzegu. Odpalilem jesze raz osobowy, jechalem na zmiane ja i wlaczylem AI, natychmiastowe wdrozenie hamowania do zatrzymania, po ponownym ruszeniu okazalo sie, ze lok sie wypial. Sprawdzenie wagonow zostawionych na szlaku - pozostaja zachamowane. Jest mozliwosc ponownego spiecia skladu i odjazdu. C++170209. Trzeba to sprawdzic na TD, odpalanie Kaliskiej zbyt dlugo trwa.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 10 Lutego 2017, 13:52:27
Tzn problem wystepuje, jesli prowadzisz pociag, i po rozpedzeniu wlaczysz autopilota przez shift+Q, czy przy przejmowaniu przez f5? Czy moze w oby przypadkach?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: joey w 10 Lutego 2017, 14:08:27
Wszystko testowane pod Linuksem Mint 17.1 z Wine 2.1, Pentium Dual CPU E2180 2GHz, 2GB RAM, Radeon HD5450 512MB RAM.
Wrazenia na eu07++170209.exe:
· Skrocony czas ladowania (Calkowo PMT zima – 5'43" na exe 481 vs 3'01" na testowanym).
· Bardzo podoba mi sie jak filtrowane sa teraz drzewa, niestety inne tekstury zaczely nieco pikselizowac z oddali, a w kabinie SP42 pojawily sie grube biale ramki wokol wskazowek (ramki.jpg).
· Bujanie jest wciaz absurdalne, bardzo ograniczajace widocznosc na lukach, zwlaszcza w S*42.
· We wspomnianym scenariuszu samochody osobowe z luboscia przejezdzaja przez zamkniete szlabany (gotcha.jpg), tylko Autosan zatrzymywal sie jak nalezy, na exe 481 jest ok.
· Zauwazalny, choc nieduzy spadek wydajnosci objawiajacy sie przede wszystkim opoznionym reagowaniem na klawisze klawiatury.

Na eu07++170209.exe zauwazylem, ze z opcja pauzy na starcie przy lokomotywach spalinowych slyszalny jest syk hamulca, ktory nie chce zniknac (moze byc kwestia systemu).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 10 Lutego 2017, 14:09:01
W obu przypadkach. F5 i shift+Q
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 10 Lutego 2017, 14:21:46
Witam.
Potwierdzam błąd z porzucaniem wagonów. Wczoraj go wymacałem na exe 170208, z tym że u mnie  wypięcie składu wystąpiło w jednym tylko pociągu ( Kaliska, sklad ET22-213 plus talboty). Chciałem sprawdzić to jeszcze dziasiaj, czy jest powtarzalne. W logu jest chyba newet ślad po tym zdarzeniu w postaci komendy "shunt velocity" czy coś w ten deseń (sprawdzę dokładnie jak wrócę do domu). Może Ai chwilowo przechodzi w tryb manewrowy? Świadczyło by o tym towarzyszące temu zjawisku wygaszenie na chwilę reflektorów i podniesienie drugiego pantografu ( u mnie tak to wygląda).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 10 Lutego 2017, 14:39:34
Zgadzam sie z tym, ze wyglada to na przejscie w tryb manewrowy. Mam te same objawy. Dodatkowo ET42 ktore przejmowalem mialo caly czas wlaczona syrene, co wlasnie sklonilo mnie do jego przejecia. Wycie ciagle syreny ET 42 obserwowalem juz wczesniej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 10 Lutego 2017, 14:40:05
&middot; Bardzo podoba mi sie jak filtrowane sa teraz drzewa, niestety inne tekstury zaczely nieco pikselizowac z oddali, a w kabinie SP42 pojawily sie grube biale ramki wokol wskazowek (ramki.jpg).
To moze byc zwiazane z ustawieniami karty graficznej w systemie -- u siebie nie obserwuje tego, nawet po wylaczeniu na probe multisamplingu (zalacznik) Tak czy owak w duzej mierze winna jest tutaj tekstura, na ktorej wskazowki maja takie wlasnie biale tlo (chyba, ze jest to efekt zamierzony) Elementy powinny miec obwodki ktore sa niejako "przedluzeniem" koloru obiektu na co najmniej kilka sasiednich pikseli, eliminuje to tego typu artefakty.

W obu przypadkach. F5 i shift+Q
Puscilem na probe sklad towarowy po TD, rozpedzilem go do ~70 km/h i wrzucilem autopilota -- autopilot istotnie wdusil hamulec, ale na ile moge powiedziec to bylo to spowodowane aktualna predkoscia szlakowa (Vd pod f2) ktora wynosila 40 km/h -- po zwolnieniu do tej predkosci autopilot zluzowal hamulce i jechal dalej, bez zatrzymywania.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 10 Lutego 2017, 15:08:23
A tam wskazówki nie są prostokątami z teksturą na alfie? W wielu starszych pojazdach tak jest.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 10 Lutego 2017, 15:14:18
Sa zdjeciami wskazowek na bialym tle, z alfa. I problem w tym ze pomalowana na czarno jest tylko ta czesc, ktora pasuje do alfy co do piksela. I przy aktywowanym mip-mappingu, czyli tak jak to powinno byc, karta graficzna ciagnie kolory takze z sasiednich pikseli, ktore w tym wypadku sa biale. Dlatego elementy normalnie umieszcza sie na tle w kolorze elementu, wtedy te dane z sasiednich pixeli nie wplywaja negatywnie na kolor koncowy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 10 Lutego 2017, 15:15:36
Witam.
W logu u mnie jest jak się nie mylę taki wpis z tego zdarzenia odprzęgnięcia ET22-213 od reszty składu:
EVENT ADDED TO QUEUE: se_i12_s1 by et22-213
EVENT LAUNCHED: se_i12_s1 by et22-213
SetVelocity    40.00     0.00 != ShuntVelocity * *
Multiple passed
EVENT ADDED TO QUEUE: se_i12_sem_ligh1 by et22-213
EVENT ADDED TO QUEUE: se_i12_sem_info_stop by et22-213
EVENT LAUNCHED: se_i12_sem_ligh1 by et22-213
EVENT LAUNCHED: se_i12_sem_info_stop by et22-213
Type: UpdateValues - SetVelocity 0.000000 0.000000
Z tego co pamiętam komenda "Shunt" odnosi się właśnie do przejścia Ai w tryb manewrowy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 10 Lutego 2017, 15:19:07
O eventach nie mam niestety zielonego pojecia :) Moge sprobowac wylapac sytuacje, w ktorych wlaczany jest tryb manewrowy, ale jesli jest to reakcja AI na otrzymana komende. to czy klopot moze byc z tym, jak oskryptowany jest scenariusz?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 10 Lutego 2017, 15:21:15
S1 dodał się do kolejki i został wyzwolony. Sprawdził, że komórka semafora nie zawiera eventu ShuntVelocity i poszedł w alternatywę, czyli podanie S1. Wygląda na zabezpieczenie przed wygaszaniem tarczy i nie wysyła komendy rozprzęgania w żadnym razie.

Cytuj
Sa zdjeciami wskazowek na bialym tle, z alfa. I problem w tym ze pomalowana na czarno jest tylko ta czesc, ktora pasuje do alfy co do piksela.
Rozumiem. Problem będzie w wielu miejscach, bo raczej nikt z naszych grafików o tym nie myślał.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 10 Lutego 2017, 15:38:48
Rozpięcie pospiesznego:
EVENT ADDED TO QUEUE: ow_tm79_ms1 by ep07-344
EVENT LAUNCHED: ow_tm79_ms1 by ep07-344
Multiple passed
EVENT ADDED TO QUEUE: ow_tm79_sem_ligh1 by ep07-344
EVENT ADDED TO QUEUE: ow_tm79_sem_info_stop by ep07-344
EVENT LAUNCHED: ow_tm79_sem_ligh1 by ep07-344
EVENT LAUNCHED: ow_tm79_sem_info_stop by ep07-344
ShuntVelocity     0.00     0.00 = ShuntVelocity * *
Type: UpdateValues - ShuntVelocity 0.000000 0.000000
Eventlauncher sieradz_zapala_semafory
Przejęcie towarowego:
Key pressed: [F5]
Loading - binary model: dynamic\pkp\et42_v2\42]kabina_a.e3d
Loading - texture: dynamic\pkp\et42_v2\42]podloga.dds
Loading - texture: dynamic\pkp\et42_v2\42]kontrolki.dds
Loading - texture: dynamic\pkp\et42_v2\42]wskazniki.dds
Loading - texture: dynamic\pkp\et42_v2\42]wskpr.dds
Loading - texture: dynamic\pkp\et42_v2\42]lampa.dds
Loading - texture: dynamic\pkp\et42_v2\42]radiotelefon.dds
Loading - texture: dynamic\pkp\et42_v2\42]fotel.dds
Loading - texture: dynamic\pkp\et42_v2\42]oslona_przeciwsloneczna.dds
Loading - texture: dynamic\pkp\et42_v2\42]sciana_boczna.dds
Loading - texture: dynamic\pkp\et42_v2\42]wskazniki_p.dds
Loading - texture: dynamic\pkp\et42_v2\42]rt9_tarcza_p.dds
Loading - texture: dynamic\pkp\et42_v2\42]grzalka.dds
Loading - texture: dynamic\pkp\et42_v2\42]podnozek.dds
Loading - texture: dynamic\pkp\et42_v2\42]tyl.dds
Loading - texture: dynamic\pkp\et42_v2\42]grzejniki.dds
Loading - texture: dynamic\pkp\et42_v2\42]przod.dds
Loading - texture: dynamic\pkp\et42_v2\42]pulpit_dol.dds
Loading - texture: dynamic\pkp\et42_v2\42]przelaczniki.dds
Loading - texture: dynamic\pkp\et42_v2\42]pomocniczy.dds
Loading - texture: dynamic\pkp\et42_v2\42]wskzeg.dds
Loading - texture: dynamic\pkp\et42_v2\42]rt9_tarcza.dds
Loading - texture: dynamic\pkp\et42_v2\42]rt9.dds
Loading - texture: dynamic\pkp\et42_v2\42]fv4a.dds
Loading - texture: dynamic\pkp\et42_v2\42]kran_zasadniczy.dds
Loading - texture: dynamic\pkp\et42_v2\42]kierunkowy.dds
Loading - texture: dynamic\pkp\et42_v2\42]pulpit2.dds
Loading - texture: dynamic\pkp\et42_v2\42]pulpit_gora.dds
Loading - texture: dynamic\pkp\et42_v2\42]pulpit2a.dds
Loading - texture: dynamic\pkp\et42_v2\42]nastawnik.dds
Loading - texture: dynamic\pkp\et42_v2\42]pulpit1.dds
Loading - texture: dynamic\pkp\et42_v2\42]szyba.dds
Loading - texture: dynamic\pkp\et42_v2\42]sufit.dds
Loading - texture: dynamic\pkp\et42_v2\42]tyl_szafki.dds
Loading - texture: dynamic\pkp\et42_v2\42]rozklad.dds
Loading - texture: dynamic\pkp\et42_v2\42]pulpit1a.dds
rozpięcie:
EVENT ADDED TO QUEUE: zw_tm11_ms1 by et42-024-a
EVENT LAUNCHED: zw_tm11_ms1 by et42-024-a
Multiple passed
EVENT ADDED TO QUEUE: zw_tm11_sem_ligh1 by et42-024-a
EVENT ADDED TO QUEUE: zw_tm11_sem_info_stop by et42-024-a
EVENT LAUNCHED: zw_tm11_sem_ligh1 by et42-024-a
EVENT LAUNCHED: zw_tm11_sem_info_stop by et42-024-a
ShuntVelocity     0.00     0.00 = ShuntVelocity * *
Type: UpdateValues - ShuntVelocity 0.000000 0.000000
EVENT LAUNCHED: zdunskawola1_rozw by et42-024-a
Type: UpdateValues - rozw 0.000000 0.000000
Cały log w załączniku.
Cytuj
Wygląda na zabezpieczenie przed wygaszaniem tarczy i nie wysyła komendy rozprzęgania w żadnym razie.
Jesteś pewny? Coś jednak rozpina loka od reszty składu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 10 Lutego 2017, 16:18:29
Próbowałem wywołać to rozprzęgnięcie na TD. Bez skutku, podobnie jak u kolegi @Tmj. Wieczorem uruchomię Kaliską na różnych exe, i zobaczę co się będzie działo. Całkiem możliwe, że powoduje to też sama sceneria. Chociaż na oficjalnych exe nie zaobserwowałem tego typu zdarzeń.
Pozdrawiam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: SQT w 10 Lutego 2017, 16:25:33
Czy ktoś zauważył że na EU07 na tym skonwertowanym exe, sprężarka działa bez przetwornicy ?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 10 Lutego 2017, 17:24:16
Urwanie się loka jest często powtarzalne, skład osobowy z 07-344, kaliska. Wciśnięcie [Shift]+[Q], AI hamuje do zatrzymania. Następnie podnosi oba patyki luzuje, przez moment światła manewrowe i odjeżdża samym lokiem. Załączniki to obrazki z wystawki i log. Jeśli nie ma tego w eventach, to Key pressed: [Shift]+[Q] przynosi więcej skutków niż tylko proste włączenie autopilota. Ponieważ zaraz wyłączyłem symulacje, w logu to będzie pierwsze od końca Key pressed: [Shift]+[Q].
Edycja.
Dopiszę jeszcze raz, lokomotywa pozostawia zahamowane wagony, co widać na screenie nie widać, ale sprawdzałem. Nie zdążyłem jednak zauważyć, czy lok do odpięcia dociskał się do wagonów. CX MANIAK, jakby co, zwróć uwagę czy jest rewers napędu i dociskanie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 10 Lutego 2017, 17:52:28
Testowo odpaliłem AI na TD, zamiast jednego semafora wstawiłem tarczę manewrową i AI nie odpina się ani na sygnał ms1, ani na ms2. Ładnie przechodzi w tryb manewrowy przy ms2.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 10 Lutego 2017, 17:59:32
CX meldował, że na TD nie dał rady sprowokować to kuku. Jechałem ponad stówkę i AI zrobiło jak zrobiło, to też nie jest tak, że zawsze. Czasem przejmuje loka na spokojnie. Czasem zachowuje się tak jakby uruchamiał go od zimnego, mimo że jesteśmy w ruchu. Po za tym, nie chodzi o żadne semafory czy tarcze, to zwyczajnie dzieje się na szlaku. Choć w obrębie stacji też widziałem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 10 Lutego 2017, 19:27:35
Tak cos mi sie dziwnie wydaje, ze to rozlaczanie moze miec zwiazek ze zmiana w funkcji przejecia kontroli przez AI. Anulowalem na probe ta zmiane, i wlaczylem przy okazji logowanie aktualnego rozkazu dla pojazdow prowadzonych przez AI, wiec bedzie troche lepiej widac, co tam sie dzieje.

Wlaczona jest tez generacja mipmap dla tekstur .dds ktorym ich brakuje -- takich tekstur jest calkiem sporo, a po zmianach w renderingu moglo to powodowac brak tekstur na obiektach, co bylo dosc zauwazalne ;d

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 10 Lutego 2017, 19:41:32
Na warunkach, na jakich udało mi się wcześniej ten błąd powielić, na tym exe już tak się nie dzieje. Wyglądało to tak, że należało najpierw samodzielnie odpalić loka i włączyć AI, jeżeli tarcza wskazywała Ms2. Wtedy faktycznie lok się odpinał, bo przechodził do kolejnej komendy z listy (Disconnect). Jeżeli włączało się AI w sytuacji, gdy Ms2 już się świeciło, ale na kompletnie zimnym loku, AI robiło wszystko po kolei dobrze i się nie odpinało. Jeżeli odpaliło się loka, ale włączyło AI przy Ms1, a dopiero po chwili dało Ms2 też wszystko działało dobrze.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 10 Lutego 2017, 22:27:02
Zajęło mi to dużo czasu, ale objechałem Kaliską z Karsznic do Ostrowa i powrót na Kaliski. Nie udało mi się urwać wagonów, choć próbowałem dziesiątki razy. AI przejmuje skład tak jak powinien. Nie zwracałem uwagi na inne rzeczy, ale wszystkie składy towarowe na szlaku poruszały się prawidłowo, lub prawidłowo przepuszczały mnie, stojąc na boku. Na screenach manewry 07-344 na tory postojowe.
tmj - Jesteś Wielki.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 10 Lutego 2017, 23:11:48
Witam.
Ja również próbowałem na różne znane mi sposoby sprowokować AI do urwania składu, bez skutku! Co więcej teraz nie wygasza reflektorów jak poprzednio, przy oddawaniu mu sterów.
Brawo Tmj!
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 10 Lutego 2017, 23:20:53
Mam wrażenie, że zmniejszył się efekt gasnącego trójkąta nadjeżdżających z przeciwnej strony loków.
... Jeśli nie ma tego w eventach, to Key pressed: [Shift]+[Q] przynosi więcej skutków niż tylko proste włączenie autopilota. ...
Tak cos mi sie dziwnie wydaje, ze to rozlaczanie moze miec zwiazek ze zmiana w funkcji przejecia kontroli przez AI. Anulowalem na probe ta zmiane, i wlaczylem przy okazji logowanie aktualnego rozkazu dla pojazdow prowadzonych przez AI, wiec bedzie troche lepiej widac, co tam sie dzieje.
Krótko mówiąc, zgadłem.
Nie wstawiałem loga z jazdy, jeśli jest potrzebny, to mam z archiwizowany.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 11 Lutego 2017, 07:50:33
Odpaliłem z ciekawości Całkowo SN61, teraz wyzwalanie zdarzeń z klawisza działa, ale hamulec pomocniczy w SN61 nie. Dziwny bug, bo widać, że klawisz prawidłowo steruje kranem, ale skład w ogóle nie hamuje. Co również dziwne, hamulec zespolony hamuje dużo gorzej niż na starym exe, czyli próba zatrzymania się przed kozłem oporowym zakończyła się przyciśnięciem składu do kozła. Biorąc pod uwagę, że jechałem 20km/h, hamowanie rozpocząłem jakieś 400m od kozła, miałem pełen ZG i ustawienie hamulca P - po prostu coś jest nie tak z tym hamulcem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: RoboBatman w 11 Lutego 2017, 12:50:07
Kolego @tmj,chcąc stestować exe o nazwie "eu07++170210.rar" wybrałem sobie do jazdy byka ET22-R004. Chciałbym zgłosić iż na tym exe nie działa przyhamowanie poślizgu które znajduje się pod klawiszem "ENTER". Nie wiem czy tylko u mnie tak jest czy u innych też. Teraz druga wiadomość -tym razem dobra - ciesze się, że na tym exe, sceneria "TD" wczytuje się błyskawicznie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 11 Lutego 2017, 12:56:50
SN61 w ogole jakis dziwny jest :)  kiedys moze uda sie go rozgryzc, ale jeszcze nie teraz.

Na razie naprawilem obsluge pythona w bardziej zaawansowanych typach. Nawiasem mowiac, tekstura 2k na ekrany to troche przegiecie, 1k chyba bedzie wygladac calkiem przyzwoicie, zwlaszcza przy nieco ulepszonym renderingu, a obciazy system tak z 4x mniej.

Przy okazji, jest taki dosc ogolny problem logiczny na styku otwierania drzwi I obslugi ekranow -- uzywaja one tych samych klawiszy, co prowadzi do roznych sytuacji, od smiesznych takich jak AI wlaczajaca/wylaczajaca ekran zamiast otwierac drzwi na stacjach (w ST45), po bardziej powazne jak 186-2 otwierajaca drzwi na przystanku, i nie bedaca w stanie jechac dalej, bo dopoki drzwi sa otwarte wlaczony jest hamulec dynamiczny, co uniemozliwia zwiekszenie ciagu, a drzwi zamknac nie moze, bo nie ma tego w konfiguracji :d

edit:
Kolego @tmj,chcąc stestować exe o nazwie "eu07++170210.rar" wybrałem sobie do jazdy byka ET22-R004. Chciałbym zgłosić iż na tym exe nie działa przyhamowanie poślizgu które znajduje się pod klawiszem "ENTER". Nie wiem czy tylko u mnie tak jest czy u innych też.

O ile dobrze pamietam to w innych egzemplarzach ET22 dzialalo to, nie wiem czy ten sie akurat czyms rozni, czy tez cos sie w miedzyczasie popsulo, sprawdze.

edit2:
z tego co widze w widoku z zewnatrz, to po wprawieniu kol w pozlizg i nacisnieciu Enter so one na krotka chwile przyhamowane do zera, ale w tym czasie trzeba zmniejszyc ciag, bo w przeciwnym razie po chwili kiedy system przestaje dzialac i silnik znowu zaczyna napedzac kola na wysokich obrotach, to znowu zaczna sie one slizgac. To nie tak ma dzialac?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 11 Lutego 2017, 13:17:51
Hehe, widzę że cofnąłeś się o miesiąc z datą ;) Enter daje bodajże przyhamowanie i posypanie piaskiem. Na pewno nie powinno dojść do stanięcia kół w miejscu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 11 Lutego 2017, 13:25:38
O faktycznie, glupia literowka :)  tzn moze zle sie wyrazilem, one sie zatrzymuja 'w miejscu' w sytuacji, gdy sklad buksuje przy narzuceniu zbyt duzej sily zanim wszystko sie ruszy z miejsca (bo na poziomie kodu ten system na twardo wylacza flage poslizgu, i powoduje zmiane przeliczania predkosci obrotowej na tryb 'zwykly' tzn na podstawie predkosci poruszania sie lokomotywy. Jesli poslizg mial miejsce w ruchu, to beda sie krecic 'luzno' dopoki silnik znow nie dojdzie do glosu. Nie wiem czy tak to ma byc, tak juz bylo i nie zagladalem tam za bardzo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 11 Lutego 2017, 13:26:42
Pseudodrzwi trzeba wywalać gdzie się da. Chciałem zrobić alternatywę, ale syf w samej obsłudze drzwi mnie trochę przyhamował. Dla pojazdów bez drzwi, chciałem pod te klawisze przypisać universale nie robiące fizycznie nic. Tylko zapalające lampki, odtwarzające dźwięki i ruszające przełączniki, używające starych kluczy drzwiowych dla kompatybilności z modelami i mmd. Została kwestia od czego uzależnić ich obecność i możliwie ładnego wciśnięcia tego w kod.
VS na xp nie postawię z tego co widzę, więc zostajecie sami, póki nie kupię nowego komputera.

W traksie jest inny problem. Kierownik otwiera drzwi w wagonach. Lokomotywa nie ma już drzwi w fiz od dawna. Hamulec postojowy był pisany z myślą o EZT i włącza się przy otwartych drzwiach. No i przy wagonach też łapie. Co ciekawe mimo braku wpisu drzwi w lokomotywie, wciśnięcie klawisza odpowiedzialnego za zamknięcie drzwi je "zamyka" i ściąga blokadę jazdy. Świta mi, że z yB daliśmy wpis na obecność postojowego do fiz.

Co do SN61, to yB pracował nad nową przekładnią hydrokinetyczną, w pewnych konfiguracjach pracującą podobnie jak mechaniczne sprzęgło. Działało to w miarę dobrze, lepiej od obecnego sprzęgła na pewno, tylko nie udało mu się zrobić sprzęgła na nastawniku, tak jak w SM03 to jest. Źródłami niestety się nie podzielił. Dobrze byłoby to przepisać na cpp i zintegrować. Kaczuchę poświęcimy, jak nie uda się rozwiązać problemu.
Uciążliwą przekładnię ma także machajka, ale to problem niszowy.

Co do ekranów, traxx i dragon mają 1k*2k na dwa ekrany. Coś ma większą? Przy 512 napisy byłyby raczej nieczytelne. Można sprawdzić skalując na wyjściu, ale bez automatu skalującego wszystkie współrzędne i czcionki, przerabianie ręczne pod małą rozdzielczość byłoby męczące.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: matek123 w 11 Lutego 2017, 13:30:18
Nawiasem mowiac, tekstura 2k na ekrany to troche przegiecie, 1k chyba bedzie wygladac calkiem przyzwoicie, zwlaszcza przy nieco ulepszonym renderingu, a obciazy system tak z 4x mniej.
A jak wtedy będą wyglądać tabelki które są narysowane z linii o grubości 1-2 px?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: pinokio w 11 Lutego 2017, 13:31:07
U mnie na exe eu07++170210 fps na Kaliskiej zwiększył się z 20 do 60, skrócił się również czas wczytywania scenerii, super. Na EU07 sprężarka działa bez konieczności włączenia przetwornicy, nie słychać również wentylatorów oporów rozruchowych.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 11 Lutego 2017, 13:35:49
Co do ekranów, traxx i dragon mają 1k*2k na dwa ekrany. Coś ma większą?
No z tego co widze to tekstura ek1 w 186_v2 ktora robi za tlo ma 2048x2048. Mysle ze przy rysowaniu na 1k to i tak byloby ok, bo ekrany nie maja w normalnych warunkach wiecej niz 500 pikseli na ekranie, a przeskalowaniem w dol z rozmiaru bazowego zajmuje sie karta graficzna. Ale ze skrypt pythona ma to wszystko zakodowane na sztywno, to sprawdzenie wymagaloby sporo recznego dlubania.

edit:
A jak wtedy będą wyglądać tabelki które są narysowane z linii o grubości 1-2 px?
Trudno powiedziec, ale na przyklad linie 1-2 px w 6dg, na pulpicie uzywajacym tekstury 512x512 wygladaja tak jak w zalaczniku. imo calkiem wyraznie. Nie jest to oczywiscie produkt pythona, ale z punktu widzenia silnika tekstura to tekstura, zrodlo nie robi mu specjalnie roznicy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: youBy w 11 Lutego 2017, 13:50:39
Pojedyncze ekrany normalnie mają rozdzielczości 640x480 i 800x600. Nie wiem, czy któryś z pojazdów nie ma więcej.

Co do poślizgów, to trzeba do tego podejść trochę inaczej, ale nie mam jeszcze gotowego rozwiązania.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 11 Lutego 2017, 13:51:23
Może zmieniłeś, ale tekstura z pythona nie była rozmywana przy skalowaniu. Z cienkich linii robiły się pływające, zanikające linie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 11 Lutego 2017, 13:54:56
No wlasnie zmienilem, dlatego wspominam :)  W przeciwnym wypadku faktycznie nizsze rozdzielczosci wygladalby tak sobie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 11 Lutego 2017, 18:03:18
ET41_v1 na ostatnim exe++ zrobiło mi oblot jednym członem :) Szkoda, że ten pociąg i tak nie miał przewidzianego powrotu, bo ciekaw jestem, czy by pojechał w takim stanie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 11 Lutego 2017, 19:51:55
W końcu odpaliłem coś do jazdy. Drzewa przy nowym filtrowaniu jakoś mniej mi się podobają, ale to kwestia przyzwyczajenia.
Luzujący skład strasznie skacze przy rozpychaniu buforami. Kwestia 40 km od zera, czy coś zmieniałeś w kroku obliczeń tutaj? Wcześniej całymi obiektami mi rzucało, ale takiego efektu nie widziałem.
Brak dźwięku wentylatora oporów odbiera większość frajdy z jazdy.
Filtrowanie paskudnie wygląda na ścianach lasu. One maja spory kawał alfy u góry na tle nieba.
Nie działa liczenie jednostek w pythonie "unit_no". Pewnie kolejny bug sprzęgu depotowego. Rozwala to ekran w en57a.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 11 Lutego 2017, 22:22:21
W końcu odpaliłem coś do jazdy. Drzewa przy nowym filtrowaniu jakoś mniej mi się podobają, ale to kwestia przyzwyczajenia.
Luzujący skład strasznie skacze przy rozpychaniu buforami. Kwestia 40 km od zera, czy coś zmieniałeś w kroku obliczeń tutaj? Wcześniej całymi obiektami mi rzucało, ale takiego efektu nie widziałem.
Brak dźwięku wentylatora oporów odbiera większość frajdy z jazdy.
Filtrowanie paskudnie wygląda na ścianach lasu. One maja spory kawał alfy u góry na tle nieba.
Nie działa liczenie jednostek w pythonie "unit_no". Pewnie kolejny bug sprzęgu depotowego. Rozwala to ekran w en57a.
Z tego co widze w kodzie, unit_no jest zwiekszany dla jednostek polaczonych z flaga 128, czyli nie zadziala przy 'standardowym' laczeniu na 55. Wentylatory sa naprawione, beda w nastepnej wersji .exe
Fizyki w zasadzie nie ruszalem, wiec jakiekolwiek skoki to zapewne cos co powstalo przy translacji. Nie bardzo rozumiem co znaczy rozpychanie buforami, jesli mozesz dac mi opis jak wywolac efekt moge sprobowac sie przyjrzec.

Krawedzie na teksturze lasu to niestety konsekwencja kombinacji dwoch czynnikow -- raz, wszystkie tekstury sa ustawiane domyslnie na 'zawijanie' w pionie i w poziomie. A dwa, mapowanie jest ustawione na cala powierzchnie tekstury, czyli mipmapping powoduje, ze gorna krawedz ciagnie piksele z samego spodu, ktory z reguly jest zielony i nieprzezroczysty.
Jakims tam rozwiazaniem mogloby byc dodanie cienkiego paska alfy na samym spodzie tekstury drzew -- wtedy gora zrobilaby sie przezroczysta, a tak malej przezroczystosci nie powinno byc widac przy gruncie. Lepszym wyjsciem byloby dodanie kontroli zawijania do tekstur, np przez dodawanie S albo T do parametrow w nazwie. Opcjonalnie polaczone z troche bardziej konswerwatywnym generowaniem koordynatow dla drzew itp. Tzn zamiast zakresu 0-100% uzywac cos w style 1-99%

A teraz z zupelnie innej beczki: testujac na Kaliskiej, wychodzi mi ze ladowanie tekstur to ~15% calego procesu ladowania -- roznica w czasie odpalenia scenerii to 95 sek vs 112. Zastanawiam sie wiec, czy bawic sie w opoznione ladowanie tekstur, bo zysk chociaz jest, to raczej niewielki, w porownaniu do wprowadzanej komplikacji.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 11 Lutego 2017, 23:00:34
Fork z okienkami i sterowaniem na GLFW:
https://github.com/Milek7/maszyna/tree/mover_in_c++
Obecnie zepsułem WM_COPYDATA i renderowanie tekstu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 11 Lutego 2017, 23:04:58
Cytuj
Z tego co widze w kodzie, unit_no jest zwiekszany dla jednostek polaczonych z flaga 128, czyli nie zadziala przy 'standardowym' laczeniu na 55.
Moja wina, miałem jakiś lipny skład w magazynie. Na starym exe to działało, ale raczej tu naprawiłeś błąd, a nie zrobiłeś nowy.
Cytuj
Nie bardzo rozumiem co znaczy rozpychanie buforami, jesli mozesz dac mi opis jak wywolac efekt moge sprobowac sie przyjrzec.
Ustaw długi skład, zahamuj z zatrzymaniem bez luzowania, mając powietrze w początku składu. Zluzuj skład. Sprzęgi będą się rozprężać, rozpychając skład o kilkadziesiąt cm, jako że końcówka będzie dłużej zahamowana od czoła. Ale to pewnie błąd współrzędnych, bo obserwowałem to na Olechowie.
Cytuj
Lepszym wyjsciem byloby dodanie kontroli zawijania do tekstur, np przez dodawanie S albo T do parametrow w nazwie.
To byłoby chyba najlepsze. Znacznik w nazwie tekstury, wyłączający zawijanie. W pionie dla ścian lasu/płotów i w obu osiach dla drzew. Nawet jak dać v na 0.95 to góra ciągnie z dołu i pojawia się pasek na górze modelu. Próbowałem z tym walczyć przy polach i cudów nie zdziałałem.

---------
Nie działa lod w t3d. Mimo wpisu maxdist w t3d wyświetla submodel do zasięgu renderowania. E3d nie badałem póki co.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 12 Lutego 2017, 20:22:33
Uaktualnienie z poprawkami dla wentylatorow rozruchowych i domyslnego typu sprezarki, powinna wymagac teraz czego trzeba.

Rozgrzebalem system obslugi tekstur i chwile to potrwa zanim sie z powrotem caly posklada, wiec przejscie/podlaczenie glfw potrwa kilka dni. Przy okazji, chyba nie warto od razu wycinac w pien elementow tylko dlatego, ze sa zrobione w oparciu o Windows -- #ifdef _WINDOWS i niech sobie siedza dopoki nie znajdzie sie bardziej uniwersalny odpowiednik, o ile w ogole sie znajdzie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 12 Lutego 2017, 21:14:55
Witam serdecznie.
 Nie wiem czy ktoś zgłaszał. Znalazłem jeszcze jeden mały problem. Na exe C++170210, ET41-V2 (np. ET41-166) nie daje się uruchomić. Nie podnoszą się po prostu patyki. Uprzedzam pytanie, ciśnienia w zbiornikach w normie. Nawet AI nie jest w stanie nic wskórać (uruchamia sprężarkę pomocniczą, przestawia kurek trójdrożny). Na exe Next4 lub z paczki, działa bez problemu.
Pozdrawiam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 13 Lutego 2017, 08:34:39
Eeee, a możemy doprowadzić exe do stanu używalności i wrzucić już to na mastera, a potem zacząć rozgrzebywać nowe rzeczy?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 13 Lutego 2017, 09:29:08
Mamy pewne doswiadczenia, ktore swiadcza o slusznosci propozycji postawionej przez firleya. Bedzie ciezko oceniac wyglad grafiki majac bledy w sterowaniu taborem.
Podzielam tez poglad, ze nie nalezy wycinac w pien elementow opierajacych sie o windowsa. To musi byc poparte korzysciami a nie niechecia do systemu Microsoftu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 13 Lutego 2017, 12:12:13
OK, jakie bledy na chwile obecna sa jeszcze do wylapania/poprawienia? Przydaloby sie zebrac je razem, bo rozwloczone sa po kilku stronach.

- hamulec reczny SN61. byc moze hamulce w SN61 w ogole, bo glowny np. hamuje ale nie wiem, czy dostatecznie szybko, nie znam sie (zarobiony jestem)
- ET41, problemy z urchamianiem itp
- na Calkowie "exe wylatuje po zalaczeniu baterii w tamarze". Co to jest tamara D: sprawdzilem SU45, SP42 i dla pewnosci ST44, ale zaden nie wylecial.
- wysyp, prawdopodobnie przy przelaczeniu do kamery ustawionej w terenie skrotem klawiszowym. Przyjrze sie, jesli uda mi sie to wywolac u siebie. crashdump by tutaj pomogl.
- blad z brakujacym dzwiekiem kranow w ET21, EN57, od czasu wprowadzenia SPKS

czy jest cos jeszcze, o czym wiadomo?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 13 Lutego 2017, 12:13:04
Dlatego wam dostosowałem bugtrackera. Róbcie tickety, dyskutujcie na konkretne tematy i zamykajcie sobie. ;)
Tamara to SM48.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 13 Lutego 2017, 13:21:21
Tamara to SM48.
Dzieki; na TD zachowuje sie bezproblemowo, ale przy okazji wyskoczylo, ze lotos_calkowo laduje sie bez szyn, wiec cos tam sie rozjezdza w parserze, do sprawadzenia.

Z innej beczki: w kodzie obslugi tekstur sa wzmianki, ze znak | moze rozdzielac kilka tekstur, a po ":" moga byc dostarczane parametry. Czy to jest jakos wykorzystywane w praktyce? Myslalem wlasnie o umieszczeniu parametrow zawijania itp w formacie nazwa:parametry ale wolalbym uniknac tutaj jakichs konfliktow.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 13 Lutego 2017, 13:24:14
Pokaż ten kawałek kodu, bo nigdy na to nie wpadłem. Były prefiksy @ # i sufiksy %n (filtrowanie) ,n (wiele wymiennych).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 13 Lutego 2017, 13:41:44
Właśnie sprawdziłem, TEM2 działa poprawnie. Pozwoliłem sobie na mały załącznik. Szkoda, że sobota i niedziela wypadły mi daleko od komputera, sprawdziłbym to wcześniej.
Tamara to SM48.
W symulatorze nie mamy plików z nazwą SM48. Prawidłowo Tamara, to TEM2. Wiem, że to to samo, ale patrząc z punktu widzenia obsługi MaSzyny, bardziej jednoznaczna nazwa, to TEM2.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 13 Lutego 2017, 13:42:15
Pokaż ten kawałek kodu, bo nigdy na to nie wpadłem. Były prefiksy @ # i sufiksy %n (filtrowanie) ,n (wiele wymiennych).
To jest w GetTextureID() na poczatku:
    size_t pos = fileName.find(':'); // szukamy dwukropka
    if (pos != std::string::npos) // po dwukropku moga byc podane dodatkowe informacje
        fileName = fileName.substr(0, pos); // nie bedace nazwa tekstury
    pos = fileName.find('|'); // szukamy separatora tekstur
    if (pos != std::string::npos) // po | moze byc nazwa kolejnej tekstury
        fileName = fileName.substr(0, pos); // i trzeba to obciac
przy pobieraniu tekstury takie dane sa ignorowane, ale nie wiem czy to nie wyskakuje gdzie indziej. Przepuscilem na probe jedna z wiekszych scenerii przez .exe i nie bylo tam w uzyciu ani razu, ale wole sprawdzic.

Jak wyglada w praktyce ten zapis o n (wiele wymiennych) Tzn. na prostym przykladzie jak wyglada zapis, jesli to nie problem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 13 Lutego 2017, 14:00:26
Nie potwierdzam braku możliwości uruchomienia ET42-166. Załączniki pokazują ją w ruchu. Jedna uwaga, po załączeniu baterii nie daje wyłączyć się buczka nastawnikiem kierunku. W tym przypadku należy wcisnąć spację.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 13 Lutego 2017, 14:28:58
nazwa_textury_w_node_dynamic,1.ext
...
nazwa_textury_w_node_dynamic,4.ext
Działa tylko dla dynamic i wymaga jakiegoś znacznika w mmd w definicji modelu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: joey w 13 Lutego 2017, 14:48:14
Wydaje mi sie, ze wysyp SM48 na Calkowie (misja niebezpieczny pociag) ma u mnie miejsce za kazdym razem, gdy ma dojsc do wyswietlenia podpisu dla dzwieku (w tym przypadku calkowo_np_wg01-pl.txt).
Zauwazylem takze, ze wygenerowane przez eu07++170210.exe modele e3d swieca cale, jakby w t3d 'selfillum: true' bylo dla kazdego submodelu, a jest najwyzej dla kilku. Nie wiem jak generuja sie e3d, gdy nie ma zadnego submodelu z 'selfillum: true' w t3d.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 13 Lutego 2017, 14:59:11
Wrócę do SN61, hamulec zasadniczy działa, droga zatrzymania pojedynczego Ganza ze 100km/h to 740m. Dla porównania dodam, że sprawdziłem również drogę hamowania siódemki, tu droga hamowania jest 500m ze 100km/h obojętne czy to hamulec zasadniczy czy pomocniczy. Hamulec pomocniczy w SN61 nie działa, jak widać w załączniku animuje się rączka, natomiast nie rośnie ciśnienie w cylindrach hamulcowych. Jest jednak plus dla tego pojazdu, po przejściu na C++ ustąpiło gaśnięcie silnika przy sterowaniu z kabiny B. Jak pisał @Stele, wybitne przypadki błędów bez żadnej dyskusji należałoby wrzucać na bugtrackera.
Dzisiejsze posty to testy exe170212
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 13 Lutego 2017, 15:33:42
nazwa_textury_w_node_dynamic,1.ext
...
nazwa_textury_w_node_dynamic,4.ext
Działa tylko dla dynamic i wymaga jakiegoś znacznika w mmd w definicji modelu.
OK, z tego co widze ",4" itd jest czescia tekstury, wiec nie powinno sie gryzc z nowym mechanizmem. Mysle o czyms w rodzaju
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)
docelowo takze inne, ale od tych mozna zaczac.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 13 Lutego 2017, 18:21:34
Testuję cały czas przejezdność i funkcjonalność pojazdów, z tym że tym razem uruchomiłem tryb VBO i mam takie kwiatki. Z tego co widzę, to nie tylko ja mam taki problem. Problem leży w teksturach i w exe, tu pytanie, czy tryb VBO pozostanie i czy można z tym coś zrobić?
Najciekawszy wydał mi się efekt ufo, co prawda widoczny tylko z kabiny siódemki (przez szybę), Po wyjściu z loka "kosmitów" już nie było.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 13 Lutego 2017, 18:50:19
Sciezka renderowania VBO w ogole jest cokolwiek niedopracowana (brakujace skrzyzowania itp) ale z uporzadkowaniem tego wstrzymalbym sie do czasu przejscia na ulepszony renderer, jesli w ogole (bo np. moze sie okazac ze prosciej bedzie spiac calosc z jakims istniejacym silnikiem, zamiast praktycznie pisac od nowa wlasny)

W dzisiejszym uaktualnieniu male poprawki bledow i niedopatrzen -- Calkowo powinno sie teraz ladowac poprawnie, "interfejs uzytkownika" czyli teksty spod klawiszy funkcyjnych nie beda wiecej sie gryzly z otoczeniem i znikaly, co zdarzalo im sie w EZT i innych ciasnych spalinowkach. A w ramach bezuzytecznych bajerow sila smugi swiatla zalezy teraz od ilosci wlaczonych reflektorow, i pory dnia.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 13 Lutego 2017, 18:54:52
Sciezka renderowania VBO w ogole jest cokolwiek niedopracowana (brakujace skrzyzowania itp) ale z uporzadkowaniem tego wstrzymalbym sie do czasu przejscia na ulepszony renderer, jesli w ogole (bo np. moze sie okazac ze prosciej bedzie spiac calosc z jakims istniejacym silnikiem, zamiast praktycznie pisac od nowa wlasny)

W dzisiejszym uaktualnieniu male poprawki bledow i niedopatrzen -- Calkowo powinno sie teraz ladowac poprawnie, "interfejs uzytkownika" czyli teksty spod klawiszy funkcyjnych nie beda wiecej sie gryzly z otoczeniem i znikaly, co zdarzalo im sie w EZT i innych ciasnych spalinowkach. A w ramach bezuzytecznych bajerow sila smugi swiatla zalezy teraz od ilosci wlaczonych reflektorow, i pory dnia.
Wrzucisz źródła na githuba?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 13 Lutego 2017, 19:01:33
To może póki co, wyłączyć VBO. Tylko zamęt sieje i będą zbędne narzekania przy majstrowaniu w renderowaniu. U mnie VBO od początku się nie sprawdzał, a grafika na pewno obsługuje Vertex Buffer Objects. Właśnie sobie o tym poczytałem.
Siła smugi światła była już dzielona według ilości reflektorów. Dla mnie super gadżet.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 13 Lutego 2017, 19:21:25
Wrzucisz źródła na githuba?
Pchne dzisiaj, tylko zastanawiam sie czy wlaczyc przy okazji przerobiony teksture manager, bo nie ma jeszcze przywroconej sciezki dla openGL starszego niz 1.4 (czort wie, czy sa w ogole jeszcze takie w uzyciu)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 13 Lutego 2017, 19:25:43
Pchne dzisiaj, tylko zastanawiam sie czy wlaczyc przy okazji przerobiony teksture manager, bo nie ma jeszcze przywroconego rendering dla openGL starszego niz 1.4 (czort wie, czy sa w ogole jeszcze takie w uzyciu)
Moim zdaniem szkoda roboty na zachowywanie kompatybilności z czymkolwiek poniżej 2.0. (albo i nawet 3, bo właściwie każda sensowna karta graficzna w ostatnich 10 latach powinna to wspierać)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 13 Lutego 2017, 19:33:03
Moim zdaniem szkoda roboty na zachowywanie kompatybilności z czymkolwiek poniżej 2.0. (albo i nawet 3, bo właściwie każda sensowna karta graficzna w ostatnich 10 latach powinna to wspierać)
Niby tak, ale biorac pod uwage ze sa uzytkownicy z XP i roznymi laptopami to akurat na powszechna obecnosc sensownych kart graficznych specjalnie bym nie liczyl ;d  Poki co zachowanie tego co bylo specjalnie skomplikowane nie jest, porzadki mozna zrobic przy przejsciu na shadery itp.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 13 Lutego 2017, 19:44:13
Jako wywołany oświadczam, że mam wsparcie dla OGL 3.3. :P
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 13 Lutego 2017, 20:16:24
OK, jakie bledy na chwile obecna sa jeszcze do wylapania/poprawienia?
Jeśli mogę coś zaproponować, to zwiększenie nieszczelności układów pneumatycznych (głównie chodzi o hamulce). Tzn. w rzeczywistości dość często bywa tak, że przy czterdziestowagonowym składzie np. Eaos-ów z ET41 na przodzie (a więc z raz większym niż przy jednoczłonowej lokomotywie zapasem powietrza w zbiornikach głównych), sprężarki potrafią się załączać nawet co 5 minut w trakcie postoju na stacji, bo takie są nieszczelności na złączkach przewodu głównego w całym składzie. Kiedy testowałem to kiedyś w MaSzynie, spadek ciśnienia w zbiornikach głównych z 0,8-0,7MPa zajął ponad 130 minut (po długim, porządnym wyluzowaniu w pozycji jazdy i nabiciu powietrza do 0,8MPa), więc na początek proponowałbym trzynastokrotne zwiększenie nieszczelności, co powinno dać załączanie się sprężarek co ok. 10 minut, a to już będzie znacznie łatwiej przetestować w celu ostatecznej "regulacji". Nawet nie tylko przy staniu pod S1, ale też w trakcie jazdy doda to realizmu, jeśli sprężarki będą się załączać nie tylko po luzowaniu hamulców, ale też częściej podczas jazdy bez hamowania.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 13 Lutego 2017, 20:37:39
Cytuj
zwiększenie nieszczelności układów pneumatycznych
To akurat do bugtrackera trzeba zgłosić.
Pchne dzisiaj, tylko zastanawiam sie czy wlaczyc przy okazji przerobiony teksture manager, bo nie ma jeszcze przywroconego rendering dla openGL starszego niz 1.4 (czort wie, czy sa w ogole jeszcze takie w uzyciu)
Moim zdaniem szkoda roboty na zachowywanie kompatybilności z czymkolwiek poniżej 2.0. (albo i nawet 3, bo właściwie każda sensowna karta graficzna w ostatnich 10 latach powinna to wspierać)
Skoro to nie jest kłopot, to pozostawił bym jak jest i nie roztrząsał tego w tej chwili.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 13 Lutego 2017, 21:03:14
Cytuj
zwiększenie nieszczelności układów pneumatycznych
To akurat do bugtrackera trzeba zgłosić.
Ok, zrobione.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: sawe w 13 Lutego 2017, 21:58:54
Nie potwierdzam braku możliwości uruchomienia ET42-166.
Witam.
Pewnie chodzi o ET41- ... z folderu v2. Tych lokomotyw rzeczywiście nie można uruchomić.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 13 Lutego 2017, 22:47:13
Jako wywołany oświadczam, że mam wsparcie dla OGL 3.3. :P
OK, nastepne uaktualnienie bedzie eksperymentalnie z min. wymaganiem openGL 1.4, i jesli dla czyjegos sprzetu okaze sie to za duzo, bedzie na Ciebie ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 13 Lutego 2017, 23:59:37
Nie potwierdzam braku możliwości uruchomienia ET42-166.
Witam.
Pewnie chodzi o ET41- ... z folderu v2. Tych lokomotyw rzeczywiście nie można uruchomić.
Niestety musze potwierdzic. Zgadza sie, mozna wlaczyc baterie, zapalic swiatelka i nijak nie ma sposobu podniesc patyki. Przegladalem mmd i fiz, ale jest zbyt pozno aby wyciagac jakies wnioski. Oczywiscie na exe z paczki wszystko jest ok. To chyba ostatni pojazd z problemami, pojezdzilem dzis EN57 po Quarku, wydaje sie, ze jezdza bez problemow. Ale pewnosc bede mial jutro po porownaniu jazd.
PS: sprawdzana ET41-144
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 14 Lutego 2017, 01:00:17
Witam.
 Właśnie pisałem o ET41 w wersji v2 (być może za słabo to zaznaczyłem w poście, albo strzeliłem gafę z numerkiem loka). Sprawdziłem ją w różnych konfiguracjach i na kilku exe. Problem występuje od dość wczesnej wersji C++. W plikach pojazdów  v1 i v2 nie grzebałem.
  Nie wiem czy to tylko u mnie, ale jakby od wersji exe C++170212 spadła wydajność grafiki. Jest mniej fps, szczególnie gdy znajdą się inne składy w polu widzenia kamery. U kolegów jak to wygląda?
Pozdrawiam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 14 Lutego 2017, 05:11:48
Sugerowalem sie numerem lokomotywy 166 i taka wstawilem na TD. Fps akurat u mnie nie jest miarodajny. W raz z wydajnoscia podnioslem antyaliasing do 8, a w jednej scenerii do 16. Oczywiscie zerkne na to zadajac te same parametry dla roznych kompilacji.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 14 Lutego 2017, 13:55:04
Przyjrzalem sie ET41_v2, i wychodzi na to, ze nie dziala ona poniewaz brakuje wpisu animations: w plikach .mmd
Starsze wersje oryginalnego .exe radzily sobie z tym, definiujac 'domyslne' ilosci animacji w takim wypadku, ale przy przesiadce na c++ zostalo to najwyrazniej celowo wylaczone:
// ustawienie liczby modeli animowanych podczas konstruowania obiektu a nie na 0
// prowadzi prosto do wysypów jeśli źle zdefiniowane mmd

dlatego tez nie przywrocilem tej funkcji. Od nastepnego uaktualnienia w logu bedzie umieszczane ostrzezenie o brakujacym wpisie animations: zeby latwiej to bylo wylapac i poprawic w .mmd

Na probe przekopiowalem tagi animations: z et41_v1 do et41_v2 i wszystko zaczelo chodzic normalnie.

edit: co do zmian w wydajnosci, trudno powiedziec. Jakis wplyw zapewne ma przelaczenie trybu renderowania tekstur z linearnego na uwzglednianie mipmaps itp, ale tu juz wplyw bedzie miala rodzaj zainstalowanej karty i ustawienia systemowe.

edit2:
Jedna uwaga, po załączeniu baterii nie daje wyłączyć się buczka nastawnikiem kierunku. W tym przypadku należy wcisnąć spację.
To akurat jest chyba raczej uniwersalne? Tzn chyba we wszystkich lokach samo ustawienie kierunku nie wylacza czuwaka, trzeba wcisnac guzik, i wylaczy sie o ile kierunek jest ustawiony. Tak samo dziala to w EU07 i innych, i tak jest do zaaranzowane/udokumentowane w kodzie. Czy powinno to dzialac jakos inaczej?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 14 Lutego 2017, 14:14:37
Z mojego doświadczenia wynika, że w niektórych lokomotywach wystarczy ruszyć nastawnik kierunku. Co do plików mmd, miałem je porównać, ale późna pora zmusiła mnie do odwrotu. Sprawdziłem na Quark.scn jak zachowują się EN57 i EN71. Wszystkie dojechały do celu, wszystkie dają się należycie sterować. Jednak tutaj, prosiłbym kogoś o sprawdzenie jeszcze jednostek EZT, nie czuję się na siłach wydać sam wyroku 100% sprawności. Nie widać więcej zażaleń na działanie pojazdów. Jeśli chodzi o wydajność grafiki, ostatnio pozwoliłem sobie na maksymalny antyaliasing, jednak porównałem exe sprzed 12 lutego i obecne w tych samych warunkach. Mógłbym pokusić o stwierdzenie, iż fps nieco spadł, ale u mnie jest to ledwo zauważalne.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 14 Lutego 2017, 14:23:47
Z mojego doświadczenia wynika, że w niektórych lokomotywach wystarczy ruszyć nastawnik kierunku.
Akurat w ET41 i podobnych normalnie trzeba jeszcze skasować SHP przyciskiem po załączeniu baterii i ustawieniu kierunku, więc jest dobrze (pomijając, że normalnie trzeba jeszcze załączyć przełącznik rozrządu, żeby lampki SHP w ogóle się zaświeciły i zadziałał buczek oraz całe sterowanie z danej kabiny - ale tego jeszcze nie ma w MaSzynie). Jeśli jakaś ma inaczej, to już na pewno indywidualna przeróbka warsztatowa. Za pomocą nastawnika kierunkowego jest natomiast w MaSzynie zrobiona aktywacja czuwaka z danej kabiny (to, co kiedyś było chyba pod [Shift] + [W], żeby czuwak nie zadziałał w tylnej kabinie).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: El Mecánico w 14 Lutego 2017, 14:51:51
Takie małe "zamówienie" odnośnie przyszłego LD: wszędzie gdzie jest interakcja z obwodami elektrycznymi przez klawiaturę dajcie w linijce komentarz:
//__PRZENIESC_DO_LD__.
Dziękować:)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 14 Lutego 2017, 17:18:57
Ktoś wie o co tu chodzi, bo wygląda że ktoś palił coś mocnego jak to pisał
https://github.com/tmj-fstate/maszyna/blob/mover_in_c%2B%2B/World.cpp#L1245
TSubModel::iInstance = reinterpret_cast<int>( Train->Dynamic() );Train->Dynamic() zwraca *TDynamicModel, TSubModel::iInstance to int, podpisany jako "// identyfikator egzemplarza, który aktualnie renderuje model". Więc to bierze wskaźnik i wpycha go do zwykłego inta(!). Ale to jeszcze nic, bo w https://github.com/tmj-fstate/maszyna/blob/mover_in_c%2B%2B/Model3d.cpp#L669
iInstance += s->iNumVerts; // pozycja dla następnegoDodaje do tego inta zrobionego ze wskaźnika....liczbę wierzchołków?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 14 Lutego 2017, 17:41:42
To nie moje :) ale raczej nic tak niezwyklego -- ten pierwszy fragment robi sobie identyfikator z 'fizycznego' adresu obiektu w pamieci, ktory chyba pozostaje staly przez caly czas trwania programu (konkretna wartosc bedzie sie roznic miedzy uruchomieniami, ale nie musi byc identyczna) Poniewaz dwa obiekty nie moga dzielic adresu, masz gwarancje ze wartosci takich identyfikatorow beda rozne.

To drugie to nie wiem, ale to chyba jakis lokalny wariant matematyki na wskaznikach czyli np std::vector<char> foo; &foo[0] + 5 == foo[5]. Tzn nie zdziwilbym sie, gdyby ten iInstance byl w ktoryms miejscu ponownie rzutowany na wskaznik. Ale zbyt gleboko sie nie przygladalem, to jest legacy code, czyli obchodzic sie jak ze smierdzacym jajkiem -- albo wyrzucic, albo nie ruszac ;)

edit: no i oczywiscie to sobie moze dzialac przy kodzie 32-bit, ale przy przejsciu na 64 to moga wyskoczyc cuda wianki.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 14 Lutego 2017, 17:51:17
ET41_v2 poprawione. Rev: 1641.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 14 Lutego 2017, 17:52:37
edit: no i oczywiscie to sobie moze dzialac przy kodzie 32-bit, ale przy przejsciu na 64 to moga wyskoczyc cuda wianki.
No właśnie dodaję wsparcie 64bit, inaczej bym tego nie ruszał :)
Z tym TSubModel to tu są niezłe cuda, inicjalizacja TWorld przechodzi tylko jeśli sizeof(TSubModel) == 256, więc pewnie jest jakaś turbomagia na wskaźnikach.
PS: dodane jest tam tylko 8 bajtów wypełniacza, a na 64bit klasa spuchła i ma 304 bajty. świetnie.
PS2: ok, jest wyjaśnienie:
    // Ra: ta klasa ma mieć wielkość 256 bajtów, aby pokryła się z formatem binarnym
    // Ra: nie przestawiać zmiennych, bo wczytują się z pliku binarnego!
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: ic_kolobrzeg w 14 Lutego 2017, 18:44:55
EXE 170213, nie widać łuny światła reflektorów w ST43

Fałszywy alarm :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 14 Lutego 2017, 20:00:35
Wersja GLFW z ostatnimi zmianami tmj.
Zrobiłem porządek w repo, wywaliłem nieużywane pliki, nagłówki i binarki bibliotek (repo to nie jest miejsce do składowania tego), system budowania zmieniłem na cmake, pozbyłem się warningów: trochę kodu zmieniłem żeby mu pasowało, dwa warningi wyłączyłem flagami: ostrzeganie o funkcjach "deprecated" według msvc i wpisywanie doubla do float. Jeden warning wskazywał na prawdziwy błąd, chyba gdzieś przy tworzeniu TTextSound nie był podawany ostatni argument. Myślałem że uda mi się wrzucić dzisiaj 64bitowy build, ale muszę zrobić normalną serializację i deserializację E3D żeby była niezależna od układu w pamięci.
Przy porządkach bibliotek być może coś zaktualizowałem, więc dorzucam do zipa dllki.
edit: oj, coś zepusłem. zaraz poprawię
e2: coś się pokasztaniło, już nie mam dzisiaj do tego głowy
e3: ok, teraz powinno być ok: https://milek7.pl/.stuff/eu07exe/eu07xxng-7c98a177.zip
e4: jest tam jakiś błąd i niektórym psuje się po inicjalizacji TWorld, jutro coś nad tym pomyślę
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 14 Lutego 2017, 20:27:24
Milek, ja się bardzo cieszę że robisz, ale NIE ZAPYTAŁEŚ SIĘ O TO CZY MOŻNA USUNĄĆ TE LIBY. Nie przyjmę takich commitów na mastera i już. Nowy devs ma sobie ściągnąć repo i mieć wszystkie potrzebne biblioteki na dysku a nie szukać po sieci.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 14 Lutego 2017, 20:50:43
Nie przekonasz mnie dowolną ilością caps locka żeby trzymać binarki na repo :)
Można zrobić dodatkowego zipa ze wszystkimi bibliotekami żeby tylko wypakować i nie szukać osobno pythona, glfw, glut, glew, ale trzymanie tego na repo jest bez sensu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 14 Lutego 2017, 21:18:44
Sorki, wtrącę się. Nie sądzę, że firleju chciał Ciebie przekonać. Sądzę, że wyraził dezaprobatę i wolę zamykając drogę do dyskusji. Jako najstarszy w rodzinie wolałbym nie czytać takich wiadomości już na początku Waszej współpracy, to nie wróży nic dobrego.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 14 Lutego 2017, 22:53:34
Krzyśku, uważam że nie masz racji. Post Milka to nie było otwarcie dyskusji nad sensem tylko poinformowanie, że on sensu nie widzi i usuwa. Nie widzę tu oznak próby dyskusji. Więc nie ma czego prowadzić.
Milek, nie wiem czy mylisz idee z praktyką, czy nie ale twoje podejście jest ideowe a nie praktyczne. A praktyka mówi, że nasz kod nie aktualizuje używanych bibliotek zbyt często. I jeśli nie masz libów na repo to za jakiś czas możesz nie znaleźć odpowiednich w sieci (znajdź mi lib-y i dll-ki do GTK2.0.1, spróbuj) i zaczną się posty w stylu "chłopaki, podrzućcie mi liba bo skompilować nie mogę".
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 15 Lutego 2017, 00:32:23
Tak jak straszylem, dzisiejsze uaktualnienie ma eksperymentalnie wlaczone wymaganie openGL minimum 1.4 :d

Z wiekszych, chociaz --miejmy nadzieje-- niewidocznych zmian jest przerobka podsystemu obslugi tekstur I obsluga wspomnianych wczesniej w watku flag zawijania zawartosci tekstury, co powinno pomoc przy renderowaniu lasow itp (nie od razu, bo wymaga to uaktualnienia plikow scenariuszy, ale zawsze)

Ze zmian mniejszych ale bardziej widocznych, naprawilem wyswietlanie wersji tekstowej odgrywanych dzwiekow. Czyli np nowy scenariusz dla Calkowa nie bedzie sie juz wywalal po kilku sekundach :P  Nawiasem mowiac, oryginalny kod oczekiwal podania czasu wyswietlenia i ukrycia tekstu dla kazdej linii, a nie kazdy tekst w scenariuszach to ma. Na chwile obecna .exe wyswietla tego typu teksty i daje informacje w logu, o braku parametrow. Jesli zle to zinterpretowalem, to informacje z logu mozna w przyszlosci usunac.

Przy okazji poprawilem tez wyswietlanie tekstow z polskimi literami (a raczej konwersje tekstu na wersje bez polskich liter, ale wychodzi na to samo)

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 15 Lutego 2017, 02:09:12
Podawanie timingów przy napisach nie było wymagane. Przy braku całość pliku była wyświetlana na czas odtwarzania dźwięku, ewentualnie stały czas. Większość napisów nie ma timingów wpisanych, bo to krótkie komendy i nikomu nie chciało się tego formatować.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 15 Lutego 2017, 03:18:47
Aha, w sumie sensownie. Wylacze zapis do logu w nastepnej wersji.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 15 Lutego 2017, 12:32:11
Słuchajcie, czy tylko u mnie jest tak, że jak wrzucam sobie EN57 na td to nie mogę podnieś patyków na exe c++ niezależnie od wersji? (sprawdzałem te ostatnie i te starsze).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 15 Lutego 2017, 12:38:30
U mnie jezdza ;/ zwroc uwage, ze zestaw musi byc spiety sprzegiem 55 (albo -55 albo 183 jesli chcesz tez miec polaczenie 'na sztywno') bo inaczej dane sterowania z kabiny nie beda przechodzic do modulu z silnikiem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 15 Lutego 2017, 12:51:46
Zestaw mam spięty 55 nobody dla 2 i 0 nobody dla ostatniego, a pierwszy wiadomo 55 headdriver.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 15 Lutego 2017, 12:53:36
Zaraz to sprawdzę, katuję ET42 w Dionizowie. Wpis robiłeś ręcznie, czy wstawiałeś rainstedem?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 15 Lutego 2017, 12:56:02
No jak tak, to nie wiem. Chyba, ze to jakis nietypowy egzemplarz i brakuje mu wpisu animations: w .mmd, tak jak temu ET41_v2 z wczesniejszej strony. Ale te z paczki standardowej jezdza u mnie normalnie, sprawdzilem przed chwila EN57-2000 i kulal sie bez problemu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 15 Lutego 2017, 13:08:42
Wrzuć wpis na którym testujesz.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 15 Lutego 2017, 13:09:19
A wysokie napiecie kolega podlaczyl? Ustaw w starterze wszystko z wyjatkiem sprzegu ogrzewania. Musi dzialac. Chodz niewiem po co sprzeg ogrzewania skoro i tak tego nie obslugujemy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 15 Lutego 2017, 13:10:11
Wygenerowany skład w rainstedzie, wpis jest taki:
node -1 0 EN57-001 dynamic PKP\EN57_V1 EN57-001RA 6BAI  0 headdriver 55 0 enddynamic
node -1 0 EN57-001 dynamic PKP\EN57_V1 EN57-001S 6BSI  0 nobody 55 0 enddynamic
node -1 0 EN57-001 dynamic PKP\EN57_V1 EN57-001RB 6BBI  0 nobody 3 0 enddynamic
W załączniku skład gotowy do odjazdu i konsola exe. Log dla świętego spokoju. Jeśli coś wam nie odpala podawajcie nie tylko typ składu/lokomotywy, trzeba także podawać numer uruchamianego pojazdu. Ważne z punktu widzenia doświadczeń ET41
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 15 Lutego 2017, 13:10:30
Na et41 sprzegu wysokiego nie spinaj. I na et40 wersja 4 patykowa.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 15 Lutego 2017, 19:50:06
Okej, na tej wersji z wpisem EPka działa, ale kiedy zmienię na EN57-1025 to syczy hamulec cały czas. Załączam log choć nie wiem co to da.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 15 Lutego 2017, 19:57:04
Nie wiem jaki wpis jest epka, bo go nikt nie podał, proszony byłeś o podanie/wklejenie wpisu, bo tak to ganiamy się w kółko i guzik wiemy. Za chwilę wstawię po swojemu i okaże się że działa...
Ja już jestem zmęczony, dawaj ten wpis tego EN57-1025, sprawdzę co tam jest to będziemy szukać. Jak raportować, to dokładnie proszę.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 15 Lutego 2017, 20:01:09
Sorki, chodziło mi wpis od Ciebie, a zmieniłem tylko teksturę w starterze.


Sprawdziłem, syczy nadal.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 15 Lutego 2017, 20:06:17
No właśnie, zapakowałem go w rainstedzie i odpaliłem bez problemu na TD.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 15 Lutego 2017, 20:09:10
Sorki, chodziło mi wpis od Ciebie, a zmieniłem tylko teksturę w starterze.
Sprawdziłem, syczy nadal.
No, sama zmiana tekstury raczej nie ma wplywu na dzialanie. Sprawdzilem u siebie dla pewnosci -- wzialem dzialajacego 1051, zmienilem teksture w starterze na 1025 i jezdzi. Nie syczy tez, wiec obawiam sie nie bardzo wiem co tam sie moze dziac u Ciebie. Jesli instalowales jakies dodatki, moze dla pewnosci przeinstalowac paczke calosciowa, na wypadek gdyby ktores pliki ulegly uszkodzeniu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 15 Lutego 2017, 20:11:42
Mi również odpala się bez problemu i śmiga, ale cały czas od początku coś syczy i jest to dźwięk jakby odluźniacza, który jest w EN57. Sprawdziłem jeszcze ET41 i na sprzęgu 55 nie podnosiły sie patyki.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 15 Lutego 2017, 20:16:42
Ja powiem tak, albo wklejasz nam tu swoje wpisy, albo przestaję zwracać uwagę na nic nie znaczące wiadomości. Mam taki wpis tego kibla i nic nie syczy!
node -1 0 EN57-1025 dynamic PKP\EN57_V1 EN57-1025RA 6BAII  0 headdriver 55 0 enddynamic
node -1 0 EN57-1025 dynamic PKP\EN57_V1 EN57-1025S 6BSII  0 nobody 55 0 enddynamic
node -1 0 EN57-1025 dynamic PKP\EN57_V1 EN57-1025RB 6BBII  0 nobody 3 0 enddynamic
Proszę o Twój wpis każdego pojazdu, który Wam nie chce działać!
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 15 Lutego 2017, 20:18:32
Ja u siebie dla tego kibello mam taki wpis:

trainset drawinowo\IKSE1703 start 0 0
//$o Tor doświadczalny.
node -1 0 EN57-1025 dynamic PKP\EN57_V1 EN57-1025RA 6BAII  0 headdriver 191 0 enddynamic
node -1 0 EN57-1025 dynamic PKP\EN57_V1 EN57-1025S 6BSII  0 nobody 191 0 enddynamic
node -1 0 EN57-1025 dynamic PKP\EN57_V1 EN57-1025RB 6BBII  0 nobody 0 0 enddynamic
endtrainset

I działa bez kłopotu.

exe c++ 014

Dziala bez kłopotu także na poniższym wpisie, dawanym z automatu dla ezt przez startera RA:

trainset drawinowo\IKSE1703 start 0 0
//$o Tor doświadczalny.
node -1 0 EN57-1025 dynamic PKP\EN57_V1 EN57-1025RA 6BAII  0 headdriver 55 0 enddynamic
node -1 0 EN57-1025 dynamic PKP\EN57_V1 EN57-1025S 6BSII  0 nobody 55 0 enddynamic
node -1 0 EN57-1025 dynamic PKP\EN57_V1 EN57-1025RB 6BBII  0 nobody 0 0 enddynamic
endtrainset
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 15 Lutego 2017, 20:21:51
Po wklejeniu waszych wpisów działa bez problemu. Nie wiem co robiłem nie tak skoro, przy wstawienie składu z rainsted zaczyna syczeć.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 15 Lutego 2017, 20:24:27
Pamietaj ze trzeba z pol minuty zaczekać az sprezarka dobije powietrza wtedy odluzujesz.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 15 Lutego 2017, 20:24:44
Czy ja nie dość wyraźnie napisałem, że skład generowałem w rainsted? Oprócz wstawienia loka i wybrania tekstur należy skonfigurować sprzęgi w zakładce "sprzęgi" w rainsted. Za każdym wagonem należy ten sprzęg ustawić. Prosiłem o podanie Twoich wpisów ze 4 razy i co?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 15 Lutego 2017, 20:27:24
Cytuj
Oprócz wstawienia loka i wybrania tekstur należy skonfigurować sprzęgi w zakładce "sprzęgi" w rainsted

Jak widać nie dla każdego jest to jasne. Mnie ludziska zadaja pytanie jak zrobić pasażera, chodz maja opis w txt krok po kroku i za raczke do przedszkola. Wiekszosc olewa wszelkie redme i info.txt. Olewaja także faq symulatora. Stad wychodzą takie rzeczy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 15 Lutego 2017, 20:28:27
Kuźwa używam MaSzyny nie od dziś i chyba wiem, co się powinno robić, żeby dodać skład do scenerii, bo przez kilka lat jakoś nie miałem z tym problemu, a pojawia się nowe exe w C++, chcę pomóc przy wyłapaniu błędów, robię wszystko tak jak robiłem do tej pory i nagle syczy jak nigdy wcześniej... Nie jestem kurde nowym laikiem, który dopiero co zobaczył symulator i nie wie co zrobić..
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 15 Lutego 2017, 20:30:28
Jesteś laikiem, nawet nie umiesz albo nie chcesz wkleić swoich wpisów. Prostej rzeczy nie zrobiłeś! Też mam zaćmienia, każdemu może się zdarzyć zapomnieć.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 15 Lutego 2017, 20:31:32
node -1 0 EN57-1025 dynamic PKP\EN57_V1 EN57-1025RA 6BAII  0 headdriver 55 0 enddynamic
node -1 0 EN57-1025 dynamic PKP\EN57_V1 EN57-1025S 6BSII  0 nobody 55 0 enddynamic
node -1 0 EN57-1025 dynamic PKP\EN57_V1 EN57-1025RB 6BBII  0 nobody 3 0 enddynamic

Proszę bardzo, wstawiam na TD i syczy

Edit. Lecz syczy tylko jeśli wstawię w "trainset rozklad start 0.0 0.0", bo jeśli w to drugie "trainset none tor_st1_2 0.0 0.1", to problem syczenia nie występuje.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 15 Lutego 2017, 20:34:33
No a u mnie nie syczy. Tzn z początku zanim nabije powietrza do zbiornika i zanim odluzuje to syczy ale przestaje. Max pol minutki. Jak już PG osiągnie swoje ciśnienie i ZG tez a sprezarka zaraz po odpaleniu się wylaczy, to przestanie syczeć. Daj mu minutke.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 15 Lutego 2017, 20:43:20
Edit. Lecz syczy tylko jeśli wstawię w "trainset rozklad start 0.0 0.0", bo jeśli w to drugie "trainset none tor_st1_2 0.0 0.1", to problem syczenia nie występuje.
A tam nie ma czasem roznicy na TD, ze na torze start sklad zaczyna zahamowany, a na tym drugim nie? Bo to by moze wyjasnilo dlaczego w jednym przypadku syczy (bo luzuje) a w drugim nie (bo nie ma co luzowac)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 15 Lutego 2017, 20:49:42
W trybie debug mode jest krótkie syknięcie może trwa sekundę. W trybie normalnym nie mam żadnego syknięcia. Uruchamiam baterię, podnoszę patyki włączam przetwornicę i sprężarkę, jak nabije to luzuję. Luzuję nawet jak nie nabije i nie syczy. Nie wiem jaką masz paczkę i jakie masz mmd, bo zmian było od diabła:) Ale to musisz sam już ogarnąć. Zaś jeśli chodzi o wstawianie, to: trainset rozklad start 0.0 0.0
jak przypisano w TD
A propo wpisu składu, to nie jest Twój wpis na którym nic nie działało (nawet patyków nie podniosłeś), a o ten wpis prosiłem... Dla mnie to koniec tematu.
ED:
Wydaje mi się, że jeśli jest zahamowany po wczytaniu, to syczeć powinien tylko jak zaczniesz sam luzować. Jeśli odpalasz na debug mode, to jest zahamowany, ale AI na starcie nie uruchamia loka, więc go nie luzuje. Ja mam tylko krótkie syknięcie. Może nie trwa nawet sekundy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 15 Lutego 2017, 20:56:19
A tak z innej beczki. Dzisiaj uaktualnienia nie ma, ale jako ze malunek jest podobno wart tysiaca slow, to mamy trzy tysiace slow w zrzutach z ekranu :d

(dla ulatwienia, 15-ego lutego zachod slonca w Polsce ma miejsce ok. 16.50  A ambient wylaczony jest chwilowo, coby efekt bylo latwiej sprawdzic)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 15 Lutego 2017, 20:59:25
No jest odlotowo. Nawet dobrze że nie ma nowego, bo na dziś mam już dość. Z 20 razy odpalałem kaliską. O TD nie wspomnę. Niebo jakieś bezchmurne, czy bez wpisu tekstury było, tylko samo światło?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 15 Lutego 2017, 21:04:52
Nieba mamy 2 rodzaje. Skaystars czyli samo swiatlo i jak jest ciemno to same gwiazdy widać, oraz dynamic sky czyli niebo z tekstura chmur. Samo swiatlo + gwiazdy + animowana tekstura chmur nie jestem pewny czy dynamic sky nie posiada także słoneczka i księżyca.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 15 Lutego 2017, 21:09:43
Niebo jakieś bezchmurne, czy bez wpisu tekstury było, tylko samo światło?
Wyczyszczone do testow, zebym lepiej mogl sprawdzic jasnosc, bez wcinajacych sie tekstur.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 15 Lutego 2017, 21:16:13
Sorki, że jeszcze wtrącę temat syczenia.. EN57-20xx bez problemu wszystko działa, nic nie syczy, natomiast w zwykłym kiblu miałem ten inny plik mmd co mogło być przyczyną, bo 608 i 001 działają bez problemu. Mój błąd, sorki, ale wydaje mi się, że dobrze, że napisałem. Pozdr.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 15 Lutego 2017, 21:23:45
@pbzylek: Cieszę się, że mogliśmy pomóc. @tmj: Tak myślałem, że jest bez tekstury to niebo, stary dobry exek664, ale to już historia.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 15 Lutego 2017, 22:59:05
Jesteście pewni, że ten syk to odluźniacz? Ten jako-tako ogarnąłem. Problem z dźwiękami był przy piaskowaniu. Luzujące ai może łapać lekkie poślizgi, gdy bufory rozpychają mu skład i sypać piachem, co przy obecnej realizacji piaskowania generuje brzydkie dźwięki.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 15 Lutego 2017, 23:02:57
Mnie się wydaje, że coś z tym sykiem jest jednak nie tak, bo co któreś włączenie td z tym samym wpisem EN57, który działał to syk się włącza. Nie za każdym razem ale raz na 3 uruchomienia na pewno.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 15 Lutego 2017, 23:12:42
Ten syk jeśli jest, ma dźwięk podobny do upustu powietrza z PG kurkiem na przewodzie powietrza umieszczonym na końcu składu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 16 Lutego 2017, 19:24:46
Czy możemy uznać ostatnie zmiany już za w miarę stabilne? Chciałbym wrzucić zmiany na mastera i przerzucić to na oficjalne repo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 16 Lutego 2017, 19:42:03
Chyba tak, tzn. ciagle sa do ogarniecia indywidualne przypadki jak SN61, ale bardziej przesuwa sie to w strone wprowadzania nowych rzeczy i naprawiania bledow z oryginalnego exe, niz latanie dziur w c++

Tak przy okazji, czy w tej wersji ktora masz u siebie przerobka tabelki skanowania jest funkcjonalna, czy jeszcze jej czegos brakuje? Pytam bo oryginalne skanowanie jakims cudem psuje sie po wylaczeniu czesci odwolan do oswietlenia openGL, co jest nieco absurdalne, i chcialbym sprawdzic, czy wstawienie zamiennika nie opartego na wskaznikach itp uleczy to szalenstwo.

W zalaczniku aktualizacja .exe z poprawkami dla MWD of macka001, poza tym na razie bez zmian of wersji poprzedniej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 16 Lutego 2017, 19:43:31
A to duża odpowiedzialność tej oceny? Jak dla mnie, stabilność nie odbiega od exe z PC. Nie jestem w stanie wszystkiego przejeździć, nikt nie zgłasza już problemów, a te co są wydają się już bardzo drobne i raczej nie wpływają na stabilność. Do sterowania niektórych pojazdów pewnie trzeba będzie doszlifować jakieś poprawki, ale na to trzeba czasu, aż takie propozycje spłyną od użytkowników. Jeśli to potraktować jak zakończenie etapu, to wrzucaj. Po ilości poborów kompilacji, można się spodziewać opinii jeszcze innych osób.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 16 Lutego 2017, 19:50:43
Moje zmiany są w połowie drogi w tej chwili. Nieużyteczne i nieużywalne. Znaczy wszystko popsułem i jeszcze nie naprawiłem. Na razie grzebię w obsłudze W4, np wyrzucam różne rzeczy do osobnych funkcji bo niepotrzebnie to wszystko na kupie jest.Idzie mi jak po grudzie bo złapałem 2 dodatkowe projekty i teraz troszkę innych zajęć mam. Ale czeka mnie w najbliższym czasie 2 x 14 godzin w pociągu to pewnie prace posuną się do przodu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 16 Lutego 2017, 20:20:15
Powiedzcie mi, czy w ekranach Pythona było coś zmieniane? Mam ekran w EN57AKŁ i na exe c++ nie wyświetla niektórych rzeczy. Więcej w załącznikach (tam gdzie jest to całe pole EZT1 to stare exe, a tam gdzie nie ma nic to C++)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 16 Lutego 2017, 20:21:12
Już zgłaszałem. Musisz mieć sprzęg depotowy na długość jednostki. +128 do sprzęgów.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 16 Lutego 2017, 20:23:33
Okej, sorki nie doczytałem. ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 16 Lutego 2017, 22:32:37
Wrzuciłem wszystkie zmiany na mastera włącznie z dzisiejszą zmianą Maćka. Jak znajdę w najbliższym okresie chwilkę czasu to przeanalizuję co wyrzucał Milek i poczyszczę repo z niepotrzebnych plików związanych z BCB.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 16 Lutego 2017, 22:37:35
Jeszcze nie polecam, niektórzy zgłaszali że crashuje się po world init. Jak wytropię tego buga i skończę z przeróbką deserializacji dla x64 to wtedy będzie można mergować.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 16 Lutego 2017, 22:48:05
Kompilacje @tmj, u mnie nie wysypuja, dzialaja poprawnie na winxp i win7. Owszem, wysypuje sie kompilacja od Ciebie na obu systemach, ale z tego co widze to Twoje pomysly i tak na przyszlosc trzeba odlozyc.
@tmj, w jakim systemie operacyjnym kompilujesz?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 16 Lutego 2017, 23:53:48
Win10 64-bit. Nawiasem mowiac przypomnialo mi sie, ze przynajmniej jedno zrodlo wywalania, ktore jest w kodzie od dawna i raczej nie zostalo jeszcze usuniete, wystepuje jesli brakuje jakiegos pliku do dzwieku (bo np zly wpis w konfiguracji jest), bo na chwile obecna exe sie tym nie bardzo przejmuje, i probuje taki nieistniejacy dzwiek i tak odegrac.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 17 Lutego 2017, 11:36:58
Było zgłoszenie w temacie widoczności świateł semaforów. W Zwierzyńcu nie widać świecenia już od 150m. Trzeba to naprawić, na ten moment AI jest w stanie dostrzec semafor.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 17 Lutego 2017, 12:22:15
Przyznam, ze za bardzo tego nie widze, tzn w kodzie do rysowania nic nie bylo zmieniane, i porownujac te same ujecia z oficjalnego exe i przepisanego, akurat sygnaly wygladaja dla mnie praktycznie tak samo?

(zrzuty w png, bo .jpg zamordowalby widocznosc czegokolwiek)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Sawi w 17 Lutego 2017, 12:25:48
Ten problem można powiedzieć jest odwieczny i faktycznie momentami jest to dość uciążliwe.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 17 Lutego 2017, 12:30:31
Na tapecie mam Zwierzyniec, scenariusz z ED72. Tam jest specyficzna atmosfera, szaro i ponuro, postaram się dać jakiegoś screena. Jeśli nawet różnica w widoczności świateł semaforów jest nie wielka, jednak nie wystarczająca, to może trzeba się pochylić nad problemem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 17 Lutego 2017, 12:33:31
Ten problem można powiedzieć jest odwieczny i faktycznie momentami jest to dość uciążliwe.
Aha, czyli to w starym kodzie siedzi? Moze uda sie tu cos poprawic jak skoncze go odlaczac/porzadkowac, ale gwarancji nie ma -- widocznosc sygnalow to chyba bolaczka wszystkich symulatorow, dlatego daja te protezy w stylu informacji na wyswietlaczu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 17 Lutego 2017, 12:39:15
Inna widoczność jest też przez szybę z kabiny, w wielu przypadkach jej "przezroczystość" mocno przeszkadza. Twoje załączniki zrobione są z innej perspektywy. Do tej pory radziłem sobie z widocznością, dopiero Zwierzyniec objawił się negatywnie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 17 Lutego 2017, 12:48:31
Ja widzę równicę w jasności punktów na tych skrinach. Z mastera są jaśniej czerwone niż na c++. Ogólnie freespotlight trzeba by zrobić bardziej świetliste. Przecież z tej odległości to wyraźnie widać sygnał a semafor to ledwo ledwo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 17 Lutego 2017, 12:53:54
Pozwolę sobie też w PNG załączyć, aby nie zabić kompresją widoczności. Niestety ktoś nie przypisał semaforów do torów w sem_info, w związku z czym nie widać ich w tabeli skanowania (gratulacje). Screeny zrobione w Kociarach, ostatni z kabiny w kierunku naszego odjazdu. Widać cień semafora, światła już nie.
Załącznik 1 -na końcu peronu jest semafor.
Załącznik 2 -podjechałem bliżej, nadal nie widać semafora (światła)
Załącznik 3- zmiana kabiny włączona tabela skanowanie, brak światła na semaforach.
ED:
Dokładam screen sem34 i sem35, zrobiony na starym exe z paczki, jest z tego samego miejsca. Mało, ale jednak widać S1, a z drugiej strony światła na powtarzaczu.
ED1:
Forum obcięło mi pliki po uploadzie. Dokładam linki do screenów.
foto-sem1.PNG  (http://eu07.pl/userfiles/1234/foto-sem1.PNG)
foto-sem2.PNG (http://eu07.pl/userfiles/1234/foto-sem2.PNG)
foto-sem3.PNG (http://eu07.pl/userfiles/1234/foto-sem3.PNG)
foto-sem34.PNG (http://eu07.pl/userfiles/1234/foto-sem34.PNG)
foto-sem35.PNG (http://eu07.pl/userfiles/1234/foto-sem35.PNG)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 17 Lutego 2017, 16:35:42
Eksperymentalnie zwiekszylem rozmiary punktow swietlnych co powinno nieco pomoc z widocznoscia na dluzsze dystanse, ale z gory mowie, ze to jest tylko proteza wiec specjalnego szalu nie ma ;d  O czyms bardziej funkcjonalnym bedzie mozna pomyslec w przyszlosci, jak juz renderer bedzie sensowniej ogarniety itp.

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: MaciejM w 17 Lutego 2017, 16:58:22
Na 170216 zaobserwowałem trzystopniową smugę, w zależności od ilości włączonych reflektorów. Jest świetnie :D Chociaż w mojej ocenie poziom "drugi" powinien być poziomem maksymalnym, bo przy włączonych trzech reflektorach wszystko aż błyszczy. Tutaj musieliby coś powiedzieć maszyniści.

http://eu07.pl/userfiles/8463/refl_0.png
http://eu07.pl/userfiles/8463/refl_1.png
http://eu07.pl/userfiles/8463/refl_2.png
http://eu07.pl/userfiles/8463/refl_3.png
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 17 Lutego 2017, 17:03:58
@tmj, tak czy inaczej semafory na załącznikach wyglądają obiecująco, nawet jeśli to proteza. Jak tylko będzie kompilacja, wsiadam i jadę...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 17 Lutego 2017, 21:21:21
Sama zmiana wielkosci swiatel to byloby troche malo na aktualizacje :d  Dodalem przy okazji pare drobiazgow brakujacych z wersji Stele, i dalem dwie poprawki do sterowania, ktore mnie wku- denerwowaly:
- przelaczniki tylnych swiatel byly odwrocone, tzn zeby zapalic manewrowy trzeba bylo kombinowac w stylu shift + I, ale ctrl+shift+Y. 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, zamiast byc oparte na sztywno na orientacji pojazdu. To jest chyba troche bardziej intuicyjne niz mentalna gimnastyka w stylu 'patrze w lewa strone wiec nacisniecie 'w przod' przesunie mnie w prawo' itp.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 17 Lutego 2017, 21:24:22
Ha, już jadę. Ze światłami tylnymi to ktoś pewnie skomentuje, pewne, że trzeba się przyzwyczaić.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 17 Lutego 2017, 21:34:59
Uniezależniłeś może prędkość ruchu w kabinie od fps? Strasznie to wkurzało.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: maciek001 w 17 Lutego 2017, 21:40:13
Na 170216 zaobserwowałem trzystopniową smugę, w zależności od ilości włączonych reflektorów.
Swego czasu Q zrobił trzy osobne smugi do każdego z reflektorów. Na pulpicie są jeszcze magiczne przełączniki przyciemniania reflektorów, które można łatwo wprowadzić ale nie mam pomysłu pod jaką kombinacją klawiszy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: RoboBatman w 17 Lutego 2017, 21:44:08
@maciek001: co do
Cytuj
a pulpicie są jeszcze magiczne przełączniki przyciemniania reflektorów[...] ale nie mam pomysłu pod jaką kombinacją klawiszy.
proponuję kombinację :
Shift lub Ctrl+> - Rozjaśnianie reflektorów
Shift lub Ctrl+< - Przyciemnianie reflektorów
Z tego co pamiętam, taka kombinacja jeszcze nie jest używana.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 17 Lutego 2017, 21:45:26
Uniezależniłeś może prędkość ruchu w kabinie od fps? Strasznie to wkurzało.
Ah nie, tam bylo dt w kodzie ale wykomentowane, nie przyjrzalem sie specjalnie i zalozylem ze uzaleznienie jest zrobione gdzie indziej (nie bardzo mam jak sprawdzic, bo praktycznie zawsze chodzi u mnie na 60fps)  Zrobi sie w nastepnej wersji.

Na pulpicie są jeszcze magiczne przełączniki przyciemniania reflektorów, które można łatwo wprowadzić ale nie mam pomysłu pod jaką kombinacją klawiszy.
EP08_015 proponowal ctrl + shift + ? do wspolnego przyciemnienia. Przydaloby sie przy okazji dodac funkcjonalny przelacznik do kabiny -- jest wymodelowany np. w EU07 ale chyba do niczego nie podpiety.

shift + < > sa juz uzywane, w dodatku do dwoch roznych rzeczy (drzwi i/lub wyswietlacze)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 17 Lutego 2017, 21:58:14
Może przyciemnianie zrobić dopiero w wersji sterowania myszką? Wiem, daleko jeszcze... Niemniej skrótów już tyle, że trzeba ze ściągawką jeździć (żart). Semafory lepiej widać, ale dobrze nie jest. Trzeba wyjść w teren i zerknąć po ciemnicy jak to widać z końca peronu w Pabianicach. Zrobiłem dwa obrazki i wrzucam na upload, bo forum i tak mi obcina png. Może jeszcze nie czas na świecące bajery.
http://eu07.pl/userfiles/1234/foto-11.PNG (http://eu07.pl/userfiles/1234/foto-11.PNG)
http://eu07.pl/userfiles/1234/foto-22.PNG (http://eu07.pl/userfiles/1234/foto-22.PNG)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 17 Lutego 2017, 22:11:58
Na tapecie mam Zwierzyniec, scenariusz z ED72. Tam jest specyficzna atmosfera, szaro i ponuro, postaram się dać jakiegoś screena. Jeśli nawet różnica w widoczności świateł semaforów jest nie wielka, jednak nie wystarczająca, to może trzeba się pochylić nad problemem.

No trudno żeby były lepiej widoczne, skoro w tej scenerii są właśnie takie wpisy atmo, które ograniczają widoczność w granicach 1 - 250 metrów...
Cytuj
atmo 0.086 0.118 0.145 1 250 0.055 0.082 0.086 endatmo
light 500 100 1000 0.078 0.102 0.126 0.09 0.118 0.157 0 0 0 endlight
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 17 Lutego 2017, 22:18:24
Tomasz, Tobie to dobrze masz porównanie z pobytu na szlaku. Moim zdaniem właśnie @tmj zrobił te 250m. Screen przed poprawkami ze skanowaniem, do pierwszej zwrotnicy było 199m. Semafor jest sporo wcześniej i niewidoczny. Poprzednio nawet ze 150 nie było nic widać. Sprawdzę jutro jak to na Quarku widać ciemną nocą dla porównania i może jeszcze jakąś scenerię.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 17 Lutego 2017, 22:27:49
Moim zdaniem właśnie @tmj zrobił te 250m.

Nie.
Cytuj
Screen przed poprawkami ze skanowaniem, do pierwszej zwrotnicy było 199m. Semafor jest sporo wcześniej i niewidoczny. Poprzednio nawet ze 150 nie było nic widać. Sprawdzę jutro jak to na Quarku widać ciemną nocą dla porównania i może jeszcze jakąś scenerię.

Sprawdzałem na różnych exe i z tej samej odległości widać na tym wpisie atmo sygnał na semaforze. I na dedykowanym starym exe z paczki, i na exe cpp z dzisiaj. To jest tylko i wyłącznie kwestia wpisu atmo. Widzisz szary semafor tylko dlatego, że wpisy atmo w zasadzie nie są skomponowane do tła. A widoczność jest jaka jest, w życiu bywa gorsza i się jedzie. Nomen omen np. dziś:

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 17 Lutego 2017, 22:39:00
Tylko, że grafika nie uwzględnia że światło lepiej się przebija przez mgłę niż obiekty oświetlane (czyli światło odbite, musi pokonać dwa razy tą samą drogę i jeszcze masz straty na odbiciu). Więc we mgle zobaczysz sygnał na semaforze np. ze 150m a przedmiot przy torze na 20m. Dodatkowo ta sama mgła w nocy da Ci widzialność na 30 m a w dzień na 200 m. Miałem tak kiedyś za Pilznem. Leciałem autostradą 120 km/h przy widzialności drogi ok. 30m gdyż każdy samochód (czyt. jego tylne światła) który doganiałem widziałem na kilkadziesiąt sekund przed wyprzedzaniem (czyli coś ze 300m tak naprawdę).
Z tego wynika, że freespot powinien mieć wartość jasności i zanikania inaczej przeliczany względem wpisu atmo niż reszta obiektów. Nie jest też przeliczana jasność względna, tak jak obecnie dla smugi.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 17 Lutego 2017, 22:43:41
Zgadza się, że tak powinno być. Ja tylko mówię, że względem poprzedniego exe nic się nie zmieniło na gorsze ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 17 Lutego 2017, 23:29:13
Witam.
  Pamiętacie koledzy, jak Q wprowadził w exe eksperymentalnie poświatę w semaforach? Całkiem fajnie to wyglądało. Na mgłę jak znalazł.
  Byłbym zapomniał. Testowałem dla odmiany kolejowy "plankton", w postaci SM03, SM04 na TD. W nich również nie działa hamulec dodatkowy ( exe 170216). Zasadniczy też czasem wariuje. Wskazówki od manometrów sporadycznie kręcą się w kółko jak oszalałe. W sumie to dość zabawnie nawet wygląda. To będzie chyba podobny problem, jak w przypadku SN61.
Pozdrawiam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 17 Lutego 2017, 23:38:13
Poświaty freespota miały jeden spory mankament. Przy standardowej pulsacji lights 2 gasły nim zdążyły się rozpalić. Wymuszało to żonglerkę exekami przy nagrywaniu kolędy, bo zastępczego nie było widać. ;)
SM03 i SN61 mają kompletnie inne zawory i krany, więc problem nawet jak podobny, to w różnych miejscach siedzi.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: djuzi w 18 Lutego 2017, 10:06:41
Chociaż w mojej ocenie poziom "drugi" powinien być poziomem maksymalnym, bo przy włączonych trzech reflektorach wszystko aż błyszczy. Tutaj musieliby coś powiedzieć maszyniści.
Tak, to jest faktycznie za mocne i zbyt białe światło. Owszem, w rzeczywistości jest tak, że gdy wskazniki są blisko reflektora, to są przebłyszczone światłem. Światło reflektorów powinno być bardziej żółtawe.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 18 Lutego 2017, 10:27:49
Zgadza się, że tak powinno być. Ja tylko mówię, że względem poprzedniego exe nic się nie zmieniło na gorsze ;)
Ja tylko mogę się wypowiedzieć na temat tego co widzę na monitorze. Jak dla mnie pierwsza wersja po konwersji owocowała pogorszoną widocznością świateł semaforowych. Zresztą zgłaszane także było, że mijające nas lokomotywy traciły swe światła gdy znalazły się blisko nas, to jest na forum i jest faktem. Ostatnia wersja C++ jest ok, przynajmniej w sprawie semaforów, nie jest gorzej niż na wersji z paczki. Widoczność ich w Zwierzyńcu rozwiązałem indywidualnie, ponieważ męczy mnie taka jazda, zwłaszcza jak chcę zwrócić uwagę na inne elementy. Snop światła, według mnie jest i tak mniejszy niż poprzednio, wyżartych bieli jest mniej, drażni mnie faktura prążków 3, może 4 milimetrowych pionowych prążków pojawiających się po zapaleniu reflektorów. Ale taka uroda tego świetlistego mechanizmu.
Atapi, Firlejczyk, dziękuję za dogłębne wytłumaczenia funkcjonowania freespotów.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 18 Lutego 2017, 15:07:22
Tak, to jest faktycznie za mocne i zbyt białe światło. Owszem, w rzeczywistości jest tak, że gdy wskazniki są blisko reflektora, to są przebłyszczone światłem. Światło reflektorów powinno być bardziej żółtawe.
Biezacy efekt oswietlenia jest w duzej mierze modyfikowany przez parametry scenariusza tzn oswietlenie, mgle, uzyte tekstury itp. Ciezko tutaj jest dobrac wartosci, ktore sie uniwersalnie sprawdza -- te obecne byly dobierane na podstawie TD, gdzie poziom 3 wyglada jak na zalaczonym screenie. Byc moze jest to zbyt jasno, ale z drugiej strony w dedykowanych scenariuszach 'nocnych' efekt moze byc nawet o polowe slabszy, a to juz dosc ciezko zauwazyc, nie mowiac o dalszej redukcji.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: joey w 18 Lutego 2017, 15:55:34
- chodzenie w kabinie dziala teraz tak samo jak wszedzie indziej, czyli na podstawie kata obrotu kamery, zamiast byc oparte na sztywno na orientacji pojazdu. To jest chyba troche bardziej intuicyjne niz mentalna gimnastyka w stylu 'patrze w lewa strone wiec nacisniecie 'w przod' przesunie mnie w prawo' itp.
W kabinie B mamy teraz sterowanie odwrotne - lewo to prawo, prawo to lewo, przod to tyl i tyl to przod.
Ponadto zauwazylem w wersji 170214, moze i wczesniej, zmienil sie sposob filtrowania szyn i podkladow. Dawniej mozna to bylo ustawic w eu07.ini, teraz tego tam nie widze. Przy obecnych ustawieniach wyglada to moim zdaniem gorzej, niz przed zmiana. Podobnie wagony, zwlaszcza osobowe, rozmazuja sie za szybko i z nawet niewielkiej odleglosci, jesli patrzy sie pod katem, zaczynaja zanikac istotne detale, np. okna.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 18 Lutego 2017, 16:43:29
Oj, to zla wersje zaladowalem. W nastepnym uaktualnieniu bedzie jak trzeba.
Co do filtrowania duza role odgrywa teraz parametr "anisotropic filtering" kontrolowany z poziomu systemowych ustawien karty graficznej. Przy sensownych ustawieniach jak x8 albo x16 rozmycie jest w zasadzie wyeliminowane, a jednoczesnie redukuje to znieksztalcenia ktore powstaja przy wymuszaniu filtrowania linearnego.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 18 Lutego 2017, 17:30:55
Nie ma czegoś takiego jak "systemowe ustawienia karty graficznej". Wszystko ustawia się z poziomu GL. https://www.khronos.org/opengl/wiki/Sampler_Object#Anisotropic_filtering
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 18 Lutego 2017, 17:45:39
A jak nazwać te ustawienia z okna w załączniku? Wydawca sterownika określa je jako globalne. Według mnie to systemowe ustawienia karty graficznej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 18 Lutego 2017, 17:58:58
Nie ma czegoś takiego jak "systemowe ustawienia karty graficznej". Wszystko ustawia się z poziomu GL.
Nazwalem to systemowym w sensie "na ta chwile symulator nie ustawia tego w kodzie, wiec trzeba sie pofatygowac do panelu kontrolnego karty z reguly dodanego do systemu przez instalator sterownikow". Chociaz jakby sie zastanowic to mozna by go przy okazji dodac do kodu, uprosciloby to sprawe.

edit: ok, wstawilem to bezposrednio do symulatora. Filtrowanie domyslnie ustawione jest na wartosc 8, na wypadek starszych kart o mniejszej wydajnosci. Konkretna wartosc mozna sobie ustawic w .ini, zapisem
anisotropicfiltering wartosc

Przy okazji w tym uaktualnieniu powinna byc juz wlasciwa wersja sterowania w kabinie B (a takze uniezaleznienie predkosci ruchu w kabinie od fps)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: dymus w 18 Lutego 2017, 19:45:08
eu07++170218 (wcześniejsze wersje też): liczy kilometry jako dziesiątki, plus zaczyna stan od 2km dla jednostek.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 18 Lutego 2017, 21:13:45
Tak przy okazji, to czy licznik kilometrow powinien przeskakiwac co pozycje przy kazdym przejechanym kilometrze, czy obracac sie gladko, tzn po przejechaniu np. 500 m byc w polowie drogi miedzy 0 i 1 na ostatniej pozycji?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: maciek001 w 18 Lutego 2017, 21:45:34
Licznik przeskakuje o ile dobrze pamiętam. Na moich filmikach na YT nie ma niestety momenty przejścia na kolejną cyfrę.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 18 Lutego 2017, 21:52:35
Przesyłam crashdumpa z nowego exeka. Program wysypał się przy próbie ruszenia ST44 po zmianie kabiny. Używałem nowej wersji kabiny ST44 z testów, więc może to też jest jakiś przyczynek do zaistniałej sytuacji.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: ryba825 w 18 Lutego 2017, 22:11:35
Windows 10 najnowszy, sypie się na ładowaniu Pythona (td).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: sawe w 18 Lutego 2017, 22:37:41
Witam.

Jeszcze na temat ET41 i ET42. Otóż na eu07++ te lokomotywy prowadzone przez AI w czasie manewrów nie odłączają się od wagonów, tylko rozłączają się i pierwszy człon jedzie dalej. Być może występuje to tylko u mnie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 18 Lutego 2017, 23:00:00
Przesyłam crashdumpa z nowego exeka. Program wysypał się przy próbie ruszenia ST44 po zmianie kabiny. Używałem nowej wersji kabiny ST44 z testów, więc może to też jest jakiś przyczynek do zaistniałej sytuacji.
Czy to byl jednorazowy wysyp, czy cos stalego? Pobralem ta kabine z testow, wypakowalem u siebie ale tutaj dziala, tzn ST44 jezdzi normalnie, sterowana tak z kabiny A jak i z B.

Windows 10 najnowszy, sypie się na ładowaniu Pythona (td).
Sypie sie akurat na probie zgloszenia bledu, wiec bedzie trudno dojsc co tam jest konkretnie nie tak ;/  Czy jest python27.dll w katalogu, i czy laduje sie poprawnie z oficjalnym exe, albo jakims innym?

Jeszcze na temat ET41 i ET42. Otóż na eu07++ te lokomotywy prowadzone przez AI w czasie manewrów nie odłączają się od wagonów, tylko rozłączają się i pierwszy człon jedzie dalej. Być może występuje to tylko u mnie.
Komus chyba sie to tez przytrafilo wczesniej w watku. Dla pewnosci, czy czlony sa polaczone sprzegiem +128? Tzn polaczenie +191 albo -63?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: sawe w 19 Lutego 2017, 00:19:05
Cytuj
Komus chyba sie to tez przytrafilo wczesniej w watku. Dla pewnosci, czy czlony sa polaczone sprzegiem +128? Tzn polaczenie +191 albo -63?

Po zmianie sprzęgu na -63 odczepianie działa prawidłowo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: ryba825 w 19 Lutego 2017, 00:21:35
tmj, tak, miałem. Dropnąłem folder z maszyną, wypakowałem jeszcze raz i działa. Magic.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: maciek001 w 19 Lutego 2017, 01:42:49
Nie wiem czy w dobrym miejscu piszę ale cóż: mam małe "ale" co do działania analogowego kranu FVel6: dotychczasowo PoKeys sterował tym kranem tak samo jak FV4a.
FV4a ma pozycje od -2 do 6, a FVel6 ma od -1 do 6. Proponuję przerobić to w następujący sposób:
do Train.cpp przekazywać wartość od 0 do 1 i dopiero tam wyliczać dokładne położenie kranu w zależności od rodzaju ustrojstwa.
Zmiana niewielka w kodzie i prosta więc mogę się tego podjąć. Wadą tego rozwiązania jest potrzeba ponownej kalibracji kranów przez użytkowników PoKeys.
Proszę o wypowiedzenie się czy to dobry pomysł. Można pisać w PW żeby tu nie śmiecić.

Ciekawostka: FVel6 kręci się ale nie luzuje na pozycji -1 i to niezależnie czy wprowadziłem zmiany czy nie. Z klawiatury działa poprawnie. naprawiłem ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 19 Lutego 2017, 16:35:22
Na kranach sie nie znam, wiec nie bede sie wypowiadal, niech to sobie madrzejsi ludzie rozpracuja :)

W dzisiejszym uaktualnieniu: naprawiony blad licznika kilometrow, a w ramach walki z wiatrakami, tzn widocznoscia sygnalow, dodana proteza: zoom pod srodkowym klawiszem myszy. Od razu nalezy zauwazyc ze pomaga to co najwyzej srednio, ale poki co technicznie rzecz biorac swoim istnieniem (chyba) nie przeszkadza.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 19 Lutego 2017, 16:46:04
Jak już jesteśmy przy zoomie, to mógłbyś zaimplementować płynną zmianę fow? Ja bym to na scrollu widział, ale niektórzy mają pod niego wyprowadzone jakieś bajery w stylu nastawnika. Na pewno nie tak na wierzchu jak było, bo szkoda klawiatury. Może jakiś klawisz+scroll. W załączniku implementacja od Q, wymagająca nieco poprawek, których nie zdążyłem zrobić przed ucieczką z borlanda.
Jak dodasz, to ustawimy kamery należycie w ciasnych pojazdach i ci, którym nie chce się myszą machać, sobie ustawią rybie oko.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 19 Lutego 2017, 17:35:07
Do ciasnych pojazdow kupuje sie po prostu dobry monitor i tyle ;)

kontrole fov mozna dodac, chociaz chyba nie na szybko bo z tego co pamietam fov jest tez uzywany do okreslenia ktore sektory powinny byc renderowane, wiec potencjalnie moga wyjsc krzaki w stylu odswiezania tylko czesci obrazu. Moze zamiast klawiszy zrobic z tego ustawienie w .ini?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 19 Lutego 2017, 17:38:46
Ta implementacja ma opcję ustawienia w ini. Ale chodzi głównie o te ciasne pojazdy, gdzie niektórzy chcą szerszego pola widzenia by objąć wszystkie mierniki na ekranie, a niektórzy kamery w miejscu głowy maszynisty a nie metr za ścianą.
Była to jedna z pierwszych zmian wprowadzonych przez Q w zeszłym roku i nikt problemów nie znalazł.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: youBy w 19 Lutego 2017, 17:42:10
FOV powinien też wpływać na widoczność modeli - im mniejszy kąt, tym obiekty w oddali są większe.
Swoją drogą, pozycja napisów jest teraz niezależna od fov?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 19 Lutego 2017, 17:53:57
Swoją drogą, pozycja napisów jest teraz niezależna od fov?
Do pewnego stopnia bylo tak juz przedtem, ale tak, bo to raczej troche bez sensu bylo zeby o pozycjonowaniu UI decydowal kat widzenia kamery -- po wlaczeniu zblizenia UI wyjezdzalo za ekran, i trzeba by to recznie wylapywac i kontrowac.

edit: Ok, dodana eksperymentalnie kontrola fov ustawieniem w .ini:
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 37.5 - 70 stopni.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: adamst w 19 Lutego 2017, 18:56:09
O, to 45 to faktycznie było dość wąsko. W trainz jeżdżę sobie domyślnie na 55 - nie ma jeszcze efektu rybiego oka, da się ogarnąć pulpit kibelka, i co najwyżej leciutko trzeba się wychylić żeby zerknąć na prędkościomierz. Najgorszy jest SN61 - tam jest tak ciasno, że żadna kamera nie poradzi ;-)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 19 Lutego 2017, 19:14:03
Dziwna sprawa. Na sp32 nie kjreca mi się kola. Na poprzednich exe było ok. W innych modelach jest ok. Sprawdzalem na elektryku i sp42. Ciekawe w czym rzecz. Już mam. Brak wpisu animacion w mmd. Wczesniej to nie przeszkadzalo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: youBy w 19 Lutego 2017, 19:16:52
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 37.5 - 70 stopni.
Można prosić o poszerzenie zakresu do 15 stopni? Obecnie do realnych odczuć na telewizorze potrzebuję jakieś 19.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 19 Lutego 2017, 19:36:03
Dla porównania wrzucam 6 sreenów z tego co zrobił QueuedEU. Dwa są w trybie debug mode. Pokazałem maksymalne zbliżenie i oddalenie.
ED:
Kontrola zbliżenia/kąta widzenia
[shift]+[PPM] należy przytrzymać do ustalenia pożądanego widoku.
[shift]+[LPM] należy przytrzymać do ustalenia pożądanego widoku.
Regulacja jest płynna i pozostaje na wybranym poziomie po uwolnieniu przycisków.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: dymus w 19 Lutego 2017, 22:57:53
Zauważyłem, że w przypadku wygenerowania e3d na exe elementy mają zby dużą jasność, porównanie jak wygląda na wcześniejszych exe i na tym ostatnim.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 19 Lutego 2017, 23:06:02
Kontrolki w siódemce, gdzie są kontrolowane materiałem mają kolor? Wnętrza tuneli/hal (Drawinowo/Moczniki) są ciemne? Jakby w Drawinowie na nowo wygenerować e3d terenu, byłoby ok?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: dymus w 19 Lutego 2017, 23:12:09
Hmm kabina 4E taka sama jasna, plus lampki, od WS wygląda dobrze, reszta coś nie badzo (po zadziałaniu nadmiarów, załączeniu grzania ich lampki są szare, wyglądają jakby nie przyjęły barwienia materiału).
Moczniki odpalone na exe c++ stare e3d, oraz odpalone na exe c++ wygenerowane e3d na nowo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 20 Lutego 2017, 01:02:27
Można prosić o poszerzenie zakresu do 15 stopni? Obecnie do realnych odczuć na telewizorze potrzebuję jakieś 19.
Nie bardzo rozumiem jak to odczytac, zakres 15 stopni tzn +-15 od domyslnego 45? Czy jakos inaczej? Mozna to zmienic bez problemu, ale nie przypuszczalem ze ktos bedzie chcial zejsc z katem widzenia tak nisko, bo 19 stopni w pionie na ekranie 4:3 wyglada jak na screenie, tzn jakby ogladac kabine przez dziurke od klucza.

edit:
Zauważyłem, że w przypadku wygenerowania e3d na exe elementy mają zby dużą jasność, porównanie jak wygląda na wcześniejszych exe i na tym ostatnim.
Ktos juz chyba zglosil ze cos jest potencjalnie nie tak z ladowaniem plikow .t3d, ale mam u siebie tylko instalacje wersji binarnych, wiec nie mialem okazji na to zerknac.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: maciek001 w 20 Lutego 2017, 10:04:19
Na kranach sie nie znam, wiec nie bede sie wypowiadal, niech to sobie madrzejsi ludzie rozpracuja :)
Opracowałem rozwiązanie o którym pisałem. To co było do tej pory powodowało wyjście poza zakres dla kranu FVel6 (minimalna wartość -1, a podać można było -2). Przerobiłem cały kod tak jak pisałem, przekazywanie wartości położenia kranu od 0 do 1 z Console. Dopiero w Train przeliczane jest na położenie kranu w zależności od jego typu. Powinno to ułatwić dodawanie sterowania innymi kranami. Dodałem jeszcze zapis do loga wyliczonej wartości dla kranu. Dzięki temu można na bieżąco podglądać jaka jest wartość ustawiana i jak reaguje kran w symulacji.

Tak jak pisałem: wprowadzenie tej poprawki zmusi posiadaczy PoKeys do przeliczenia wpisów kalibracyjnych dlatego też pytam o zgodę Was!
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 20 Lutego 2017, 15:22:21
Wygenerowałem paczkę tga/t3d z obecnego archiwum na SVN. Potwierdzam problemy poruszone przez @Dymusa. Dodatkowo lampki SHP w EN57 nie świecą na czerwono mimo alarmu. Testy na tej paczce dopiero zacząłem, jeśli zauważę nieprawidłowości to zgłoszę. Wydaje się, że podobne "hece" były przy przejściu z tga na dds.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 20 Lutego 2017, 15:25:43
Blad w .t3d sie znalazl (zgubila sie konwersja kolorow ze skali 0-255 do 0-1, w rezultacie praktycznie wszystkie elementy byly renderowane w pelni biale), poprawka bedzie w nastepnym uaktualnieniu. Puscilbym teraz, ale chce przy okazji zmiescic ewentualna zmiane katow kamery dla youBy, o ile dowiem sie o co tam chodzi ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: youBy w 20 Lutego 2017, 16:06:50
Można prosić o poszerzenie zakresu do 15 stopni? Obecnie do realnych odczuć na telewizorze potrzebuję jakieś 19.
Nie bardzo rozumiem jak to odczytac, zakres 15 stopni tzn +-15 od domyslnego 45? Czy jakos inaczej? Mozna to zmienic bez problemu, ale nie przypuszczalem ze ktos bedzie chcial zejsc z katem widzenia tak nisko, bo 19 stopni w pionie na ekranie 4:3 wyglada jak na screenie, tzn jakby ogladac kabine przez dziurke od klucza.
Dokładnie tak to ma wyglądać – chodziło mi o ustawienie minimalnego kątu patrzenia jako 15°.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 20 Lutego 2017, 16:23:33
Hmm nie bede udawal ze rozumiem, ale ok ;)

Zmienilem dopuszczalny zakres do 15-75 stopni, powinno tez byc poprawione ladowanie .t3d
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 20 Lutego 2017, 17:21:49
Największy problemem z testowaniem paczki tga są... Trzeba hurtowo wywalać pliki E3D, co jest upierdliwe. Chyba, że macie na to jakiś sposób?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 20 Lutego 2017, 17:26:55
w bashu find . -iname "*.e3d" -delete, a w cmd to pewnie del /s /q *.e3d
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 20 Lutego 2017, 17:30:33
Kazałem szukać szukajce plików .e3d w katalogu z symulatorem, w sumie też nieźle idzie. Dzięki.
Pobrałem, zaraz sprawdzę co z mocznikami i kiblem. Poprzednia kompilacja wysypywała mi się na Całkowie sn61 w tga, ale tu trzeba kilka podejść zrobić i sprawdzić.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 20 Lutego 2017, 18:11:17
Wyłączyć tworzenie e3d?
Kod: ("eu07.ini") [Zaznacz]
convertmodels 0
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 20 Lutego 2017, 18:16:54
Wyłączyć można, ale wtedy za każdym razem długi czas wczytywania. W zasadzie poprawne tworzenie modeli e3d w exe dodawanych do paczki z teksturami dds nie jest potrzebne. Tak czy inaczej poprawny mechanizm tworzenia e3d być musi, natomiast użytkowe exe może tego wcale nie mieć. Ktoś zadecyduje? To są ważne decyzje, może na lata.
Melduje poprawne utworzenie plików w Mocznikach i prawidłowe wyświetlenie lampek. Może jeszcze komuś uda się to sprawdzić?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: dymus w 20 Lutego 2017, 18:35:31
Sprawdziłem wygenerowanie e3d na losowej kabinie jest ok, to samo dworzec w mocznikach, też jest dobrze.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 20 Lutego 2017, 19:50:02
Buildy z forka z GLFW.
Coś się zepsuło ze skalowaniem obrazka startowego ale na dzisiaj mam już dość.

32bit: https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng32-64e3e810.zip
64bit: https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng64-64e3e810.zip
Wersja 64bit szuka bibliotek pythona w katalogu python64. Trzeba do niego skopiować local z obecnego katalogu python, a DLLs i Lib należy skopiować z katalogu instalacji pythona z zainstalowanym pillow.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 20 Lutego 2017, 19:52:12
A właśnie, w buildzie TMJ też się skalowanie obrazka startowego zepsuło. Przy 16:9 zamiast być w 4:3 plus kolorowe pasy po bokach, to go skaluje.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 20 Lutego 2017, 20:09:49
A fakt, przerzucilem ustawianie perspektywy do petli renderujacej, wiec ekran startowy zostal, jak to sie ladnie mowi, z przyrodzeniem w garsci. Domyslna konfiguracje mam z oknem 4:3 wiec nie rzucilo mi sie to w oczy, poprawie przy nastepnej wersji.

edit: Ciekawostka, wersja GLFW renderuje troche inaczej (na screenach to ta po prawej) Uzywa domyslnie sRGB albo czegos?

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 20 Lutego 2017, 22:50:54
Niestety na c++ wysypuje mi na odpalaniu paczki t3d/tga. Wysypy są w różnych miejscach. Czasem po inicjalizacji pojazdów, czasem już na wstępie. Niestety nie generują się crashdumpy mimo, że od Milka7 te pliki miałem. Poprawnie wczytałem tylko Bałtyk i TD, także Moczniki. Nie wczytuje mi także scenerii kiedy wcześniej generowałem e3d innym exe. Na paczce e3d jest dobrze, nie ma wysypów, wprowadzane zmiany funkcjonują. Przykładowy log w załączniku.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 20 Lutego 2017, 23:03:40
Jest gdzies w ogole link skad mozna pobrac wersje .tga/.t3d bardziej aktualna niz 15.02?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 20 Lutego 2017, 23:06:50
Partiami dla wszystkich: http://eu07.pl/daily/
Do kupy dla rangowych: http://eu07.pl/svn/pctga/
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 20 Lutego 2017, 23:20:51
Dzieki. Do rangowego nie mam dostepu, a dzienny to tak na oko jest z 4-5gb w 40+ plikach, tu trzeba kogos z sila woli/OCD wiekszym niz moje, zeby to sobie recznie posciagac i poskladac :x  Zobacze, co sie uda wylapac na 15.02
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 20 Lutego 2017, 23:22:32
Ściągając z svn to jakieś 25GB na dysk. Uprawnienia powinieneś dostać od admina.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 20 Lutego 2017, 23:27:26
Już masz uprawnienia. A na daily masz co jakiś czas reset archiwum. Trzeba patrzeć po wadze i pobierać ostatnie przed tym jak się zmniejsza waga. Czyli:
12-Feb-2015 00:40    298M ściągasz
23-Feb-2015 05:50    2.6M już nie
24-Feb-2015 05:50    2.6M też nie
10-Apr-2015 05:54    176M tak, bo zawiera dwa powyższe
27-Apr-2015 05:50    15M    znowu nie
I tak dalej.

Ja nie odpalę większości scenerii na paczce TGA. Za mało ramu na wczytanie tak ciężkich tekstur. Efekt to abmormal termination jak braknie pamięci na wczytywanie kolejnych. Na nowych exekach nie patrzyłem, czy generuje crashdumpa w tej sytuacji.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 20 Lutego 2017, 23:34:19
Aha. No jak wylatuje na braku pamieci to tutaj za bardzo nic sie nie zrobi. Tzn moze gdyby zaczac sie bawic w generacje/wymiane danych w locie na podstawie tego co jest potrzebne/uzywane, ale w sumie to bylaby raczej sztuka dla sztuki.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 20 Lutego 2017, 23:35:53
edit: Ciekawostka, wersja GLFW renderuje troche inaczej (na screenach to ta po prawej) Uzywa domyslnie sRGB albo czegos?
Raczej nie, powinno tworzyć taki sam kontekst jak wcześniej. Trochę widzę że na alfie się różni, bo w kolorach to nie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 20 Lutego 2017, 23:40:15
To tak przy okazji. 07++NG odpala mi scenerie w paczce z tga i t3d, ale nigdy w pojeździe. Nie wiem czy wszystkie, runtime error miałem jak odpalałem Moczniki Zwierzyniec.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 20 Lutego 2017, 23:42:30
Raczej nie, powinno tworzyć taki sam kontekst jak wcześniej. Trochę widzę że na alfie się różni, bo w kolorach to nie.
Glownie wychodzi to na chmurach -- te ze 'standardowego' exe sa troche bardziej przeswietlone, tak jakby tam troche inna gamma byla. A dane zrodlowe i kod ladowania sa w sumie te same, wiec cos musi byc tam gdzie inne :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 21 Lutego 2017, 18:02:06
To tak przy okazji. 07++NG odpala mi scenerie w paczce z tga i t3d, ale nigdy w pojeździe. Nie wiem czy wszystkie, runtime error miałem jak odpalałem Moczniki Zwierzyniec.
Nazwy pojazdów przy wczytywaniu scn zamieniane są na lowercase, a po moich zamianach w parserze argumentów zachowywało oryginalne i nie znajdowało pojazdu. Zmieniłem, ale nie po co to w ogóle się zamienia przy ładowaniu scn. Co do bugów przy ładowaniu TGA i T3D to zachowanie powinno być takie samo jak w buildach tmj,  ja grzebałem tylko przy ładowaniu DDS i E3D. Jeżeli zachowanie jest inne to kiepsko, bo pewnie coś pisze po pamięci i wysypy są zależne od różnych niezależnych czynników.
32b: https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng32-62e97669.zip
64b: https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng64-62e97669.zip
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 21 Lutego 2017, 18:11:25
Nazwy pojazdów przy wczytywaniu scn zamieniane są na lowercase, a po moich zamianach w parserze argumentów zachowywało oryginalne i nie znajdowało pojazdu. Zmieniłem, ale nie po co to w ogóle się zamienia przy ładowaniu scn.
To chyba glownie jako idioto-odpornosc, tzn zeby nie bylo kwiatkow w stylu ktos sobie postawi na torach "EU07", w pliku wpisze "Eu07" i potem placz, ze mu pociagu nie znajduje.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 21 Lutego 2017, 18:22:02
O tak, teraz wylądowałem w lokomotywie tak jak powinno być. Na razie na TD. Sprawdzę scenerie z którymi jest kłopot. Póki co mogę sprawdzić tylko na 32bitowym xp.
ED:
Wysyp na Zwierzyńcu, załącznik komunikatu i log.
ED2:
Zapomniałem, paczka t3d/tga i C++NG od Milek7.
Uznałem, że trzeba ogarnąć konwersję modeli.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 21 Lutego 2017, 18:55:29
Żeby coś wymyślić to musiałbym mieć crashdumpa z debug builda, ale lepiej będzie jak to zreprodukuje u siebie. Skąd to można pobrać? W paczce 15.02?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 21 Lutego 2017, 18:59:03
Linki do paczek tga są niżej wyżej (ja mam inaczej wygląd forum ustawiony), potrzebne jest hasło do svn od admina. Natomiast crash dumpa nie ma, bo się nie wygenerował.
ED:
Dorzucam log z wczytywania Quarka, inaczej się kończy, nieudane.
ED2:
Jeszcze jeden log z Mocznikami. Chyba wystarczy na ten moment.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 21 Lutego 2017, 19:52:56
Na win xp 32 bit nie wczyta większości scenerii w tga, bo nie starczy na to ramu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 21 Lutego 2017, 20:37:34
Ja mówię o sceneriach, która zawsze się wczytują na 32bitowym winXP. Nie ma takiej scenerii, która u mnie nie wczytała się z paczki TGA na na exe 483. Powiem więcej, mam tylko 4Gb pamięci ram. Za chwilę log i screen z poprawnego wczytania i jazdy na Zwierzyńcu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 21 Lutego 2017, 22:19:34
Moczniki wysypują się tylko na moim czy też na tmj?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 21 Lutego 2017, 22:37:51
Tylko na Twoim, Sprawdzalem tworzenie dworca wmocznikach, powinny byc opisy tutaj. Z tego co napisal @Stele z paczki tga nie moge otworzyc tylko jednego scenariusza na L053. Log zatrzymuje sie na generacji e3d jakiejs budki droznika. Ze wzgledow na wspoldzielenie komputera dzis nie bedzie juz testow.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 22 Lutego 2017, 02:27:01
Z wiadomosci pozytywnych: bardziej dokladna symulacja ruchu slonca i kalkulacji oswietlenia nieba itp moze tanim kosztem zrobic zauwazalna roznice.

Z wiadomosci negatywnych: niektore z istniejacych scenerii wychodza na tym tak sobie, bo jesli nie dzieja sie latem, to po godzinie 17-ej jest juz praktycznie ciemno, podczas gdy do tej pory w symulatorze bylo w miare widno tak gdzies do 21-ej. Tak wiec ewentualne dodanie tego kodu do exe zapewne wiazaloby sie z poprawkami w kilku sceneriach. Pytanie, czy komus by sie chcialo to zrobic :x

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: szczawik w 22 Lutego 2017, 06:29:31
Opisz zmiany w sceneriach do wykonania. Chodzi o wpisy pogody i oświetlenia?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 22 Lutego 2017, 08:07:09
Po konsultacjach ze @Stele, uznalismy ze wklejanie dalszych logow i screenow nie ma sensu. Tak jak napisalem wczesniej scenerie, ktore u mnie sie nie wczytuja z paczki tga na exe od @tmj i @Milka 7 wczytuja sie na exe483 z svn. Nie udaje sie wczytasc sceneriiL053 na wszystkich exe, scenarisz tlk i tu wyglada ze ilosc tekstur tga kladzie temu kres. Tu nasuwa sie pytanie, czy symulator korzysta ze swapa (biorac pod uwage wolnej pamieci przydzielonej na dysku, to nie), jesli nie to jaka jest mozliwosc wprowadzenia tego i jak wplynie to na wydajnosc i plynnosc symulacji. Czy jest sens podjac temat, skoro powszechnie uzywany jest dds? Kiedys nawet w dds przyjdzie sceneria przekraczajaca ilosc pamieci ram w niektorych komputerach.
Z wiadomosci pozytywnych: bardziej dokladna symulacja ruchu slonca i kalkulacji oswietlenia nieba itp moze tanim kosztem zrobic zauwazalna roznice.
Jesli zmiany beda tylko w plikach scn, to jest ich na tyle niewiele, ze ewentualny pacz do poprawnie dzialajacego exe nie powinien byc zadnym klopotem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 22 Lutego 2017, 14:46:29
Opisz zmiany w sceneriach do wykonania. Chodzi o wpisy pogody i oświetlenia?
Glownie tak. Tzn w niektorych sytuacjach sprowadza sie to do parametru movelight, w zalaczniku roznica na Kaliskiej miedzy wartoscia domyslna (240) i po przesunieciu 'kalendarza' o miesiac z kawalkiem wstecz (200)

W niektorych scenariuszach jak np. Calkowo samo movelight moze byc niewystarczajace, i w takiej sytuacji trzeba by tez troche przesunac zegar, rozklad i przypisane do czasu eventy. Okazjonalnie moze tez zajsc potrzeba zmiany tekstury uzytej dla nieba -- np. Baltyk uzywa tekstury ze sloncem przebijajacym przez chmury z polnocy, co nie bardzo zgadza sie z rzeczywista pozycja slonca, oswietlajacego scenerie z poludnia :d
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 22 Lutego 2017, 19:23:11
Po konsultacjach ze @Stele, uznalismy ze wklejanie dalszych logow i screenow nie ma sensu. Tak jak napisalem wczesniej scenerie, ktore u mnie sie nie wczytuja z paczki tga na exe od @tmj i @Milka 7 wczytuja sie na exe483 z svn. Nie udaje sie wczytasc sceneriiL053 na wszystkich exe, scenarisz tlk i tu wyglada ze ilosc tekstur tga kladzie temu kres. Tu nasuwa sie pytanie, czy symulator korzysta ze swapa (biorac pod uwage wolnej pamieci przydzielonej na dysku, to nie), jesli nie to jaka jest mozliwosc wprowadzenia tego i jak wplynie to na wydajnosc i plynnosc symulacji. Czy jest sens podjac temat, skoro powszechnie uzywany jest dds? Kiedys nawet w dds przyjdzie sceneria przekraczajaca ilosc pamieci ram w niektorych komputerach.
Przepraszam że zapomniałem powiedzieć wcześniej, ale jeżeli chodzi o generowanie e3d na moim exe to nie spodziewałem się zbytnio żeby zadziałało, bo robiłem zmiany w strukturze submodelu i nie przerabiałem jeszcze zapisywania. Pewnie jutro przepiszę to tak jak z wczytywaniem, serializacja zamiast bezpośredniego kopiowania pamięci.
Co do wczytywania T3D/DDS to przed chwilą przetestowałem i nie powinno być problemów. (L053 zajęło 3.3GiB, ale 4.2GiB wirtualnej więc nie dziwne że na 32bit nie rusza). Jeżeli jednak są to proszę zgłaszać.
Swap jest kontrolowany przez system operacyjny, nie przez aplikację. Do tego powyżej 4GiB na 32bit to żaden swap i tak nie pomoże. Jeszcze jest kwestia pamięci karty graficznej (to też zależne od sterownika, bo może kombinować z przerzucaniem nieużywanych tekstur do pamięci głównej).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 22 Lutego 2017, 20:27:26
Poprawki cyklu dobowego wrzucaj i się nie przejmuj. Od lat mieliśmy to zrobić, tylko nikt nie umiał. Jakbyś miał trajektorię dla słoneczka i księżyca, to też dodaj. Że atmosfera się zmieni po poprawce błędnego liczenia oświetlenia, rzecz oczywista, ale czy zła? Movelight i tak raczej nie jest używany z teksturowymi czaszami nieba.
Co do dziwnych kierunków światła, lata temu Ra obracał je do zgodności z kierunkami geograficznymi. Jak coś jeszcze jest dziwne, to wypisujcie które czasze w bugtrackerze. Się poprawi.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 22 Lutego 2017, 21:29:57
Milek, to L053 na XP Ci nie ruszy. Żeby to mogło działać możesz zająć maks 2GB dla exe.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: szogun w 22 Lutego 2017, 21:43:07
Ja tylko powiem jedno, szacun ogromny dla @firleju że zaczął temat i postanowił ruszyć MaSzynę ku lepszemu, no i również szacun dla @tmj że pomaga w debugu i dodaje swoje ficzery, kurde, jak zdebugujecie kod do końca i ulepszycie to my tu Trainza będziemy mieć :D Żeby nie był offtop, zdecydowanie trzeba obrócić nieba do stanu faktycznego, bo zauważyłem, szczególnie na Bałtyku że oświetlenie nie zgadza się ze stanem sky'a. Ten screen z Kaliskiej wygląda naprawdę dobrze i tego brakowało, bo movelight zastosowane przez @Ra chyba nie za bardzo miało coś wspólnego z oświetleniem kierunkowym. Wszystko było wyświetlane jakby dostawało światlo z każdej strony. Na TD jest domyślnie movelight w scn i wygląda to benadziejnie, a najgorsze że nowi twórcy dobierają do tego jasność, kontrast i nasycenie tekstur.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Mariusz1970 w 22 Lutego 2017, 21:58:29
Ja dodam tylko, ze u mnie na Win98, na teksturach tga, bmp, tex L053, L61, L144 dzialaja bezproblemowo. Exe wiadomo jakie ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: maciek001 w 22 Lutego 2017, 22:55:56
Zrobiłem PullRequesta z moimi plikami.
Ktoś wywalił z Globals.cpp Console::ModeSet(iFeedbackMode, iFeedbackPort); przez co nie dało się włączyć jakiegokolwiek starego FeedBacka. Było to zabezpieczoną jakąś zmienną qp ale takowej już nie ma także "leży luzem".

Moje poprawki trochę zmieniają samo sterowanie i możliwość dodania kranów innych niż FV4a i FVel6 do sterowania analogowego (przekazuje się wartość od 0 do 1). Dla FVel6 jest nowy if zrobiony (wcześniej razem z FV4a był) bo jest całkiem inny zakres działania. Dodałem swoje debugowania i udostępnię plik w excelu z całym opisem (jak już skończę).

Nie wiem czemu "nie widzi mi" poprawnie iPause. Chciałem zrobić uzależnienie, że jak pauza to prędkość poruszania jest 0. Nie działa mi to niestety na razie.

Wszystko było testowane i działa - PoKeys też. Nie trzeba wprowadzać żadnych zmian do zmiennych kalibracyjnych PoKeys.

PS:
Jak skończycie przenosić całą MaSzynę na C++ do końca tego roku to zamówię Wam po kracie piwa z dostawą do domu.
Trochę spóźnienia mieli chłopaki ale myślę, że i tak zasłużyli!
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 23 Lutego 2017, 03:05:13
Wywalilem dzisiaj na probe wszystkie pliki .e3d i .dds z instalacji, wrzucilem zamiast tego .t3d i .tga i patrzylem co sie stanie. Wyskoczyl przy okazji jeden blad w ladowaniu plikow, ale po usunieciu wszystkie scenariusze weszly bez wiekszych problemow (sprawdzilem tylko po jednym dla kazdej scenerii, bo za dlugo by trwalo) Wychodzi na to ze 3gb na karcie graficznej na razie wystarcza, nawet dla .tga ;)

Jakbyś miał trajektorię dla słoneczka i księżyca, to też dodaj.
Slonce jest juz wstawione (tzn trajektoria, samego slonca na razie nie rysuje) z ksiezycem na razie sie wstrzymuje, bo chyba jest tez ksiezyc dolaczony do modelu gwiazd ktory jest w symulatorze, a chce podpiac te gwiazdy przy rysowaniu nocy, bo ladne sa. I glupio by bylo, jakby sie dwa ksiezyce zrobily :d   Poprawilem przy okazji troche oswietlenie w nocy (w zalaczniku, Kaliska po zakonczeniu jazdy) i chyby nie jest zle. Ale pare rzeczy musze jeszcze z oswietlenia podpiac z powrotem, wiec uaktualnienia na dzisiaj nie ma jak dobrze pojdzie bedzie jutro. A potem moze bedzie mozna myslec o laczeniu z wersja Milka.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 23 Lutego 2017, 11:16:07
Na służbowym wiekowym monitorze uwalonym farbą, to widzę jedną wielką czarną plamę i kilka mniejszych jasnych plamek. :D
Księżyc można wywalić z pliku t3d notatnikiem. To wskazówka godzinowa zegara, kręcąca się w okół środka czaszy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 24 Lutego 2017, 00:39:14
Na służbowym wiekowym monitorze uwalonym farbą, to widzę jedną wielką czarną plamę i kilka mniejszych jasnych plamek. :D
Znaczy sie, jest jak trzeba ;)

Wstepna wersja uaktualnienia ze zmianami oswietlenia:
- implementowana prawidlowa sciezka slonca w zaleznosci od daty/czasu
- implementowane bardziej wierne oswietlenie nieba
- efektem ubocznym jest nieco inne oswietlenie scen (ambient gra troche mniejsza role, kolor swiatla i mgly jest bazowany bardziej na aktualnym oswietleniu nieba)
- gwiazdy sa standardowym elementem sceny, pojawiaja sie gdy zrobi sie dostatecznie ciemno, nie trzeba wiec ich recznie dokladac do sceny
- ogolny poziom oswietlenia w scenie jest kalkulowany troche inaczej; pod klawiszem F2 w trybie poza pojazdem wyswietlany jest aktualny poziom jasnosci, dla latwiejszego ustawienia parametrow w obiektach itp
- oswietlenie kabiny jest teraz widoczne w widoku zewnetrznym, jesli model ma low poly interior. ograniczeniem jest tutaj jednakowe oswietlenie calego wnetrza, ale to limitacja biezacego podejscia do modeli.

Chwilowo wylaczone:
- renderowanie chmur
- zmiana jasnosci w tunelach itp

Po zmianach oswietlenia czesc scenariuszy rozgrywa sie teraz po zmroku, zamiast jak do tej pory przed. Do pewnego stopnia mozna to "naprawic" zmiana parametru movelight w scenariuszu. Np "calkowo_niebezpieczny_pociag" po przesunieciu z movelight 231 na movelight 191 rozgrywa sie (do pewnego stopnia) jeszcze przed zmierzchem.

edit: oprocz exe w paczce jest tez model gwiazd, ktory wedruje do katalogu "models".

edit2: macku, jesli mozesz zrobic pull request bez solucji VS to bylbym wdzieczny, bo nie bardzo widzi mi sie "upgrade" do wersji, ktorej nie mam :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 24 Lutego 2017, 12:02:23
Nie wiem czy to dobry moment, ale na przyszlosc przydaloby sie zastanowic nad odlegloscia swiecenia freespotow, ktore zdaje sie ograniczone sa parametrem maxdistance rodzica. Czasami chce sie zwiekszyc widocznosc samego swiatla (semafory mam konkretnie na mysli).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: matek123 w 24 Lutego 2017, 12:10:15
To da się załatwić hierarchią.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 24 Lutego 2017, 12:49:06
- oswietlenie kabiny jest teraz widoczne w widoku zewnetrznym, jesli model ma low poly interior. ograniczeniem jest tutaj jednakowe oswietlenie calego wnetrza, ale to limitacja biezacego podejscia do modeli.
Masz jakiś pomysł jak to rozwinąć? Chodzi mi zwłaszcza o podświetlenie modelu. Kombinowałem z modyfikacją emisyjności materiału, ale to wymaga rekompilacji e3d.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 24 Lutego 2017, 13:47:52
To da się załatwić hierarchią.

No, tylko ze teraz trzeba to robic we wszystkich glowicach ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 24 Lutego 2017, 14:06:57
Masz jakiś pomysł jak to rozwinąć? Chodzi mi zwłaszcza o podświetlenie modelu. Kombinowałem z modyfikacją emisyjności materiału, ale to wymaga rekompilacji e3d.
Na ta chwile w modelu jest pojedynczy 'slot' dla uproszczonego wnetrza, wiec wymusza to w praktyce jeden scalony modul. Rozwiazaniem mogla by tu byc np rozbudowa mozliwosci definiowania kabin z podaniem wersji "low poly" modelu dla kazdej kabiny indywidualnie. Przy takim ustawieniu daloby sie oswietlac indywidualne moduly low poly, na podstawie obsadzenia kabiny i uzytych przyciskow oswietlenia.

Nie wiem czy to dobry moment, ale na przyszlosc przydaloby sie zastanowic nad odlegloscia swiecenia freespotow, ktore zdaje sie ograniczone sa parametrem maxdistance rodzica. Czasami chce sie zwiekszyc widocznosc samego swiatla (semafory mam konkretnie na mysli).
Z freespotami w ogole dziwnie jest, np te na semaforach pala sie az do maksymalnego zblizenia, ale te na swiatlach lokomotyw znikaja juz po przyblizeniu na ~100-200 m, co powoduje efekt 'wylaczania' swiatel na srednim dystansie. Wie ktos moze, jak to jest ustawione/zorganizowane?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 24 Lutego 2017, 16:56:58
Proszę spojrzeć na załącznik, słońce jest o godzinie 18 dokładnie na północy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: maciek001 w 24 Lutego 2017, 17:18:57
No ale w czym problem? Noc polarna + zmiana strefy czasowej (ktoś nie uwzględnił 6 godzin) :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 24 Lutego 2017, 17:28:20
Na ta chwile w modelu jest pojedynczy 'slot' dla uproszczonego wnetrza, wiec wymusza to w praktyce jeden scalony modul. Rozwiazaniem mogla by tu byc np rozbudowa mozliwosci definiowania kabin z podaniem wersji "low poly" modelu dla kazdej kabiny indywidualnie. Przy takim ustawieniu daloby sie oswietlac indywidualne moduly low poly, na podstawie obsadzenia kabiny i uzytych przyciskow oswietlenia.
Nie zrozumiałem o co chodzi. Umiałbyś zrobić tak, by świeciły poszczególne submodele lowpoly? Nadal byłoby jako jeden obiekt, ale podzielone na n lampek. W lokomotywie odpowiadałyby za obie kabiny, w wagonie za korytarz i różne przedziały.
Jeśli obecna koncepcja jednak się utrwali, proszę o dodanie do ai zarządzającego składem, gdzieś tam gdzie obsługa drzwi i kierownika jest, zapalanie światła w wagonach. Choć pewnie nie będzie to możliwe, jak stan światła jest w kabinie. Muszę zobaczyć w kodzie jak to zrobiłeś...

Z freespotami w ogole dziwnie jest, np te na semaforach pala sie az do maksymalnego zblizenia, ale te na swiatlach lokomotyw znikaja juz po przyblizeniu na ~100-200 m, co powoduje efekt 'wylaczania' swiatel na srednim dystansie. Wie ktos moze, jak to jest ustawione/zorganizowane?
Freespoty są zrobione tak, jak modelarz je zrobił. Zazwyczaj ustawiało się znikanie na jakąś odległość, gdy przestawały być wyraźne światła jako mesh. Jak chcesz to normalizować, to potrzebny jest automat, który łapałby ten parametr w t3d. Notatnikiem raczej tego nie złapię, za dużo parametrów pomiędzy.

Krzysiu, czy to północ? Kaliska nie trzyma zgodności z kierunkami geograficznymi.

------------
Po zmianach w ambiencie smuga jest do ponownej kalibracji. TD, północ, wszystkie reflektory włączone a efekt jakbym tor próbował kolejką PIKO oświetlać.
Przeskok freespota może wynikać z nowego filtrowania tekstur. Kiedyś świecącego mesha światła nie rozmywało aż tak, freespot był mniejszy i nie było widać przeskoku przy tych samych parametrach.
Wysypało przy zamykaniu programu. Crashdump w załączniku.
Coś z konwersją azymutu na literkę kierunku się popsuło. Mam N, EN, N, EE, S, W, S, WW.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 24 Lutego 2017, 18:02:49
Cytuj
Krzysiu, czy to północ? Kaliska nie trzyma zgodności z kierunkami geograficznymi.
W załączniku cała sceneria i wycinek na którym jest Dworzec Kaliski. Jeśli przyjąć, że odwracamy scenerię o 180 stopni (tak wynika z ałącznika i mam google, to słońce będzie nadal w złym punkcie. Przynajmniej tak mi się wydaje. Oczywiście zależy to od pory roku. Zakładam, że STV trzyma kierunki świata jak należy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 24 Lutego 2017, 18:06:39
Proszę spojrzeć na załącznik, słońce jest o godzinie 18 dokładnie na północy.
Obawiam sie, ze w symulatorze polnoc jest gdzie indziej :)

(pod klawiszem F2 poza pojazdem mozna sobie zobaczyc dokladny kat. Gdzie konkretnie zakonczy bieg slonce zalezec bedzie od szerokosci geograficznej i daty; w lecie zdazy sobie powedrowac nieco bardziej na zachod, w zimie mniej)

edit: ale swoja droga to faktycznie jest obrocone nieprawidlowo. na oko w ciagu dnia bylo dobrze wiec sie nie przygladalem, ale po testach przy ustawieniu na 21 marca wychodzi, ze trzeba obrocic calosc o 90 stopni)

Nie zrozumiałem o co chodzi. Umiałbyś zrobić tak, by świeciły poszczególne submodele lowpoly? Nadal byłoby jako jeden obiekt, ale podzielone na n lampek. W lokomotywie odpowiadałyby za obie kabiny, w wagonie za korytarz i różne przedziały.
Jeśli obecna koncepcja jednak się utrwali, proszę o dodanie do ai zarządzającego składem, gdzieś tam gdzie obsługa drzwi i kierownika jest, zapalanie światła w wagonach. Choć pewnie nie będzie to możliwe, jak stan światła jest w kabinie. Muszę zobaczyć w kodzie jak to zrobiłeś...
Na upartego daloby sie to zrobic. Na razie wyglada to tak, ze DynamicObject ma dwa dodatkowych parametry, definiujace kolor i aktualna sile oswietlenia wnetrza. Mozna by z tego zrobic tablice, ktora trzymala by te wartosci dla indywidualnych sub-modeli, i przy renderingu oswietlenie byloby dostosowywane na podstawie zgodnosci wpisu w tabeli z nazwa sub-modelu. Kontrole oswietlenia da sie wtedy realizowac np. wysylana wzdluz skladu komenda typu "swiatlo submodel wartosc", ktora ustawiala by sile swiatla w podanym sub-modelu w kazdym pojezdzie, ktory ja otrzyma.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 24 Lutego 2017, 18:40:43
Proszę spojrzeć na załącznik, słońce jest o godzinie 18 dokładnie na północy.
Obawiam sie, ze w symulatorze polnoc jest gdzie indziej :)

(pod klawiszem F2 poza pojazdem mozna sobie zobaczyc dokladny kat. Gdzie konkretnie zakonczy bieg slonce zalezec bedzie od szerokosci geograficznej i daty; w lecie zdazy sobie powedrowac nieco bardziej na zachod, w zimie mniej)

edit: ale swoja droga to faktycznie jest obrocone nieprawidlowo. na oko w ciagu dnia bylo dobrze wiec sie nie przygladalem, ale po testach przy ustawieniu na 21 marca wychodzi, ze trzeba obrocic calosc o 90 stopni)
Nie napisałem tego, aby marudzić. Zwyczajnie zwróciłem uwagę na fakt niegodności z rzeczywistością bo ten teren dobrze znam osobiście. Uważam, że światła w lokomotywach są za słabe. I tu powiem tak, one zwyczajnie są do niczego nawet jak określimy w przybliżeniu jakąś wartość jasności która zadowoli wszystkich. Póki co nie widać drutu jezdnego a słupy trakcji dostają oświetlenie (pojawia się różnica jasności) na 10 metrów przed lokiem. Testowałem przed chwilą... Wiadomo, Kaliską.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 24 Lutego 2017, 19:05:44
Nie napisałem tego, aby marudzić. Zwyczajnie zwróciłem uwagę na fakt niegodności z rzeczywistością bo ten teren dobrze znam osobiście.
Dobrze sie stalo, bo po testach faktycznie wyszedl blad -- opieralem sie na danych z HUD, a w tych z kolei byl krzak po konwertowaniu tekstu z Borlanda na std. I w rezultacie wszystko bylo obrocone o 90 stopni. W uaktualnionej wersji poprawione sa oba bledy, a przy okazji takze ekran startowy, zeby nie rozciagal sie w trybie szerokoekranowym, bo kompletnie o tym zapomnialem.

Co do oswietlenia, to obawiam sie ze tutaj duzo nie da sie zrobic przy zastosowanej metodzie, tzn po zmroku to jest jeszcze w miare, ale im pozniej tym gorzej i zwiekszanie 'sily' smugi raczej tu nie pomaga. Trzeba bedzie pomyslec o wprowadzeniu tutaj faktycznego zrodla swiatla.

Aha, @Stele ten wysyp bedzie sie na razie okazyjnie zdarzal, to wychodzi gdy logger dostaje polecenie dopisania tekstu do logu, a obiekt ktory wydal taka instrukcje jest w miedzyczasie usuwany, i zabiera tekst ze soba. Zeby to usunac trzeba poprawic logger, a ze wyskakuje to w zasadzie tylko, gdy program jest juz zamykany, specjalnie mi nie zalezalo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 24 Lutego 2017, 19:48:10
I teraz się zgodzę z pozycją słoneczka, a Kaliską obrócić trzeba o 180 stopni.
Ze smugą należało by wrócić do ostatnie wersji na 3 razy, jak komuś za widno, sobie ściemni. W końcu w paczu było jasno jak cholera i ściemni się nie dało. Dla mnie teraz nijak to wygląda.
A na "prawdziwe żarówki" to czekają wszyscy...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: queuedEU w 24 Lutego 2017, 20:00:44
Jest szal jak sie patrzy, ale nie wiem jak sie przyspiesza czas. Niby w debugmode CTRL+F6 czy jakos tak, moze 2x szybciej sekundy leca ale czy da sie przyspieszyc o minuty na sekunde?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: surgeon w 24 Lutego 2017, 20:36:55
Jest jeszcze Shift+Ctrl+F6. Ale może to otwierać tunele czasoprzestrzenne, dlatego lepiej tego nie używać. Szczególnie przy niskim FPS.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 24 Lutego 2017, 20:38:32
Manipulacji czasu nie dotykalem w ogole (nie wiem nawet jak sie to wlacza) wiec jest tylko to, co od zawsze bylo w exe :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: queuedEU w 24 Lutego 2017, 20:46:24
Daj tam w OnKeyPress w world.cpp

  if (Console::Pressed(VK_CONTROL) && Console::Pressed(VK_F6)) Global::fTimeSpeed = 1000.0;
  if (Console::Pressed(VK_CONTROL) && Console::Pressed(VK_F8)) Global::fTimeSpeed = 100.0;
  if (Console::Pressed(VK_CONTROL) && Console::Pressed(VK_F9)) Global::fTimeSpeed = 1.0;

  if ((Console::Pressed(VK_CONTROL)) && (Console::Pressed(VkKeyScan('='))) ) GlobalTime->UpdateMTableTime(60);    //Global::iViewMode=VK_F6;
  if ((Console::Pressed(VK_CONTROL)) && (Console::Pressed(VkKeyScan('-'))) ) GlobalTime->UpdateMTableTime(10);

albo jakiekolwiek inne jezeli te sa zajete z controlem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 24 Lutego 2017, 22:38:51
Podmienilem skale dla istniejacych klawiszy, prosciej bedzie :)

w debug mode:
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
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 25 Lutego 2017, 09:40:33
Godzina 12 w południe. Przy movelight 0 niezwykle nienaturalnie.

Kolejny przy movelight 150.

Jakie parametry atmo stosować najlepiej?

Eksperymentalnie uzylem na tym exe skydynamicstratus od ra i ciekaw jestem czemu nie widać chmur? I czemu niebo jest przypisane na stale? Nie można go zmienić starterem. Ponadto w nocy brak smugi, tzn jest ale jak w kolejce TT to nie do przyjecia.  Egipskie ciemności (ustawienie na marzec godz 19:30).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 25 Lutego 2017, 10:59:12
Renderowanie chmur wylaczono. @tmj napisal o tym, stad nie dziala zmiana w starterze a niebo jest stale. Zmiana jest tymczasowa. O smudze i swiatla h napisalem wczesniej. Prosilem o powrot do wersji wlaczanej na 3 razy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 25 Lutego 2017, 14:02:14
Cytuj
Renderowanie chmur wylaczono.

Ciekaw jestem dlaczego. Przy okazji w dynamicsky macie księżyc. I on dzialal. TMJ koniecznie odblokuj mozliwosc zmiany nieba i to co wprowadzil ra.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 25 Lutego 2017, 14:06:24
Panowie, spokojnie. Wyłączył by łatwiej nam było testować gradient tła bez zabawy we wpisy. Ra wprowadził błędny algorytm ruchu słońca i gwiazdy. Gwiazdy są, algorytm poprawił.
A jak jesteśmy przy Ra, to ma on uwagę do prac nad niebem. W ciągu dnia, po świcie, jasność powinna być stała. Ludzkie oko i aparaty fotograficzne normalizują obraz na podstawie naświetlenia.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 25 Lutego 2017, 15:27:16
Jasnosc tak, ale temperatura barwowa juz nie. Oko ma wlasciwosci akomodacyjne, uklady pomiarowe w aparatach, nie. Jak to wziac pod uwage nie wiem, w przypadku fotografii stosowalo sie filtry korekcyjne w zaleznosci od temperatury barwowej bo materialy swiatloczule nie maja na nia tolerancji. W dobie cyfrowek tego problemu nie ma, bo mamy mozliwosc dodtosowania recznego lub automatem.  Ta temperatura wazna jest z punktu widzenia odbioru jasnosci swiatla, oko ludzkie nie jest tak samo czule w calym zakresie barw, stad rozne doznania przed i po poludniu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 25 Lutego 2017, 16:01:11
Godzina 12 w południe. Przy movelight 0 niezwykle nienaturalnie.
Niestety model nie jest idealny, i przy ustawieniach slonca na sredniej wysokosci (ktore przy ustawieniu 0 czyli dniu biezacym jest jak najbardziej naturalne: http://www.edukator.pl/zmianamiejscwschoduizachodusoca,2987.html ) wchodzi tam zbyt duzo czerwieni itp. Byc moze da sie to ewentualnie skorygowac, zobaczymy.

dynamicsky jest chwilowo wylaczony, bo oprocz dynamicznego ksiezyca ma tez dynamiczne slonce, ktore wedruje sobie sciezka zupelnie inna od 'prawdziwego' slonca (podobnie zreszta jak i dynamiczny ksiezyc) Po ogarnieciu tego wlacze z powrotem, dlugo to nie potrwa.

A jak jesteśmy przy Ra, to ma on uwagę do prac nad niebem. W ciągu dnia, po świcie, jasność powinna być stała. Ludzkie oko i aparaty fotograficzne normalizują obraz na podstawie naświetlenia.
Tutaj bym sie spieral, bo golym okiem widac roznice w sile oswietlenia tych samych obiektow w zimie i lecie, przy czystym niebie i przy niebie zachmurzonym, a roznica jest tu wlasnie ilosc dochodzacego do Ziemi swiatla. Owszem, oko sie w jakichs tam granicach dostosowuje, ale chyba jednak nie tak, ze caly czas widzimy obiekty tak samo.

A teraz z innej beczki. Jako ze smuga jaka jest, kazdy widzi (a raczej, ze jej nie widac) mamy dzisiaj eksperymentalnie wprowadzone zamiast niej rzeczywiste zrodla swiatla. Od razu uprzedzam ze szczegolnego szalu nie ma -- 'klasyczne' swiatla openGL dzialaja w oparciu o oswietlenie wierzcholkow, wiec o ile efekt jest ok na torach i otoczeniu (a i tutaj trzeba bylo wprowadzic podzial odcinkow prostych na wiecej niz jeden segment) to takie elementy jak siatka terenu czy np. perony doswietlaja sie srednio, jesli w ogole.

Ponadto implementacja jest 'na szybko' czyli taka ze od kodu zeby bola. W tym momencie swiatla przypisane sa na sztywno do modelu prowadzonego. Bardziej prawidlowa bylaby/bedzie tabela wszystkich pojazdow w scenerii razem z "wirtualnym" stanem ich oswietlenia, i przydzielaniem kilku swiatel 'rzeczywistych' do najbardziej stosownych celow na podstawie polozenia kamery itp. No i docelowo kalkulacja oswietlenia z dokladnoscia per pixel, ale to juz po przestawieniu na silnik obslugujacy shadery itp.

Sila swiatel dobrana jest "na oko" wiec jesli jest zbyt jasno/ciemno/cos tam to prosze krzyczec.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 25 Lutego 2017, 16:15:53
Odpaliłem się na Quarku i oświetla teren całkiem ładnie. A że cały trójkąt, to z kabiny zbytnio nie widać, gorzej na zewnątrz. Wywaliło mnie jednak jeszcze przed odjazdem.

Dobra, wyglądało znośnie póki nie ruszyłem tego źródła światła. Nope, vertex shader to nie jest dobra droga, nawet przy absurdalnej teselacji.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 25 Lutego 2017, 16:24:21
Nie żebym marudził, ale IMO dorzucanie teraz kolejnych funkcji ze starego opengl to strata czasu, lepiej wykorzystać go do przejścia na shadery.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 25 Lutego 2017, 16:50:26
Akurat w tym wypadku specjalnie to nie przeszkadza imo, bo to niejako efekt uboczny przy rozlaczaniu .exe i istniejacego kodu renderera. a i po przejsciu na shadery symulator jakies pojecie gdzie sa aktualnie swiatla do renderowania musi miec, shader sam sobie tego nie urodzi. Wiec to tak troche na przyszlosc, troche na teraz.

@Stele, wysypalo sie przy skanowaniu trasy, ale samo mi to za wiele nie powie, bo trudno powiedziec konkretnie na czym. Gdzie to bylo, i czy jest powtarzalne, czy jednorazowo tak?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 25 Lutego 2017, 17:04:08
Nie żebym marudził, ale IMO dorzucanie teraz kolejnych funkcji ze starego opengl to strata czasu, lepiej wykorzystać go do przejścia na shadery.
Nie wiem czy dobrze zrozumialem, ale jesli akurat chodzi o swiatla lokomotyw, to powinny byc przynajmniej takie na moment budowy nowego exe, aby cokolwiek bylo widac w ciemnosciach. Po ciemku testy sensu maja malo a moze wcale. Nawet jesli jet to opengl. No chyba, ze ktos jest w stanie wprowadzic shadery, to chetne potestuje.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 25 Lutego 2017, 18:32:15
@Stele, wysypalo sie przy skanowaniu trasy, ale samo mi to za wiele nie powie, bo trudno powiedziec konkretnie na czym. Gdzie to bylo, i czy jest powtarzalne, czy jednorazowo tak?
Koniewice en57, skanowanie do W4. No ale nie wiadomo który skład wtedy leciał, nie? Odpaliłem się ponownie na składzie obok co miał szybciej wyjazd i przez kilka minut nic nie wysypało, wiec raczej losowe.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 25 Lutego 2017, 19:38:11
To są najlepsze światła jakie mieliśmy w exe. Wiem, mają wady, ale jak je usuniesz, to ja nie chce innych. Druga sprawa, że te światła ma tylko skład obsadzony przez nas, mijające nas składy nie prezentują takich żarówek. Nie chodzi o narzekanie, stwierdzam tylko fakt i miło by było dostać w temacie jakieś info. Załączam tym razem linki do plików PNG z prezentacją oświetlenia dla osób nie testujących nowości exe. Linki, ponieważ po zmianie warunków dodawania załączników obrazki mają po 1,5mb wagi, szkoda.
http://eu07.pl/userfiles/1234/foto-zarowki_1.PNG (http://eu07.pl/userfiles/1234/foto-zarowki_1.PNG)
http://eu07.pl/userfiles/1234/foto-zarowki1.PNG (http://eu07.pl/userfiles/1234/foto-zarowki1.PNG)
http://eu07.pl/userfiles/1234/foto-zarowki2.PNG (http://eu07.pl/userfiles/1234/foto-zarowki2.PNG)
http://eu07.pl/userfiles/1234/foto-zarowki3.PNG (http://eu07.pl/userfiles/1234/foto-zarowki3.PNG)
http://eu07.pl/userfiles/1234/foto-zarowki4.PNG (http://eu07.pl/userfiles/1234/foto-zarowki4.PNG)
http://eu07.pl/userfiles/1234/foto-zarowki5.PNG (http://eu07.pl/userfiles/1234/foto-zarowki5.PNG)
@tmj, postarałeś się.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 25 Lutego 2017, 19:44:15
Druga sprawa, że te światła ma tylko skład obsadzony przez nas, mijające nas składy nie prezentują takich żarówek. Nie chodzi o narzekanie, stwierdzam tylko fakt i miło by było dostać w temacie jakieś info.
Tak jak pisalem oryginalnie, ta implementacja jest "na tu i teraz" zeby cos w ogole bylo widac ;)  Na dluzsza mete .exe bedzie mialo podreczna liste wszystkich kandydatow w scenariuszu, i dostepne swiatla beda "przydzielane" na podstawie stopnia oswietlenia pojazdow i odleglosci od kamery.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 25 Lutego 2017, 19:48:28
Czy coś podobnego można zrobić dla ulicznych latarni? Tekstury przy poziomie gruntu fatalnie wygladają i migoczą. Jeszcze pytanko, nie mogę wrócić pod F1 do opisu stanu pojazdu, (pozycja nastawnika, hamulca, ciśnienia...). Widać tylko docelową stację z godziną odjazdu. Tryb debug mode. Robiłeś tu jakąś zmianę?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 25 Lutego 2017, 20:03:05
Latarnie raczej dlugo jeszcze nie, jest ich po prostu zbyt duzo, tutaj nawet samo przejscie na shadery nie zalatwi sprawy (potrzebny bylby najprawdopodobniej deferred renderer, bo inaczej sie komputer zes... tresuje liczac oswietlenie wszystkich punktow)

F1 prawdopodobnie sie popsul gdy dopisywalem przyspieszenie czasu pod F3 itd, sprawdze. Tak przy okazji, to troche inaczej dziala tez tryb wireframe pod F7, obejmuje teraz w zasadzie wszystko.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 25 Lutego 2017, 20:10:17
Tryb wireframe pod F7 jest świetny:) Natomiast pod [shift]+[F1] zmienia mi się czas, każde wciśnięcie posuwa o 5 minut. Zestresowaniem komputera nie jestem zainteresowany, chwilowo musi być jeszcze ten co mam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 25 Lutego 2017, 20:12:07
Latarnie są statyczne, wiec znośnie by wyglądały jakby obecnego plane trochę podnieść i traktować jako mapę światła. No dopóki coś by nie wlazło w snop światła.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 25 Lutego 2017, 20:51:53
Natomiast pod [shift]+[F1] zmienia mi się czas, każde wciśnięcie posuwa o 5 minut.
Tak, Q chcial miec przyspieszenie czasu na poprzedniej stronie, wiec podpialem jako dodatkowe funkcje pod F1 bo tam jest zazwyczaj zegar, wydawalo sie w miare logiczne :)  Przelacznik na wyswietlanie parametrow na zmiane z czasem sie znalazl/naprawil, bedzie w nastepnym uaktualnieniu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 26 Lutego 2017, 06:18:42
Światła wyglądają faktycznie najlepiej, tylko 1 problem - oświetlenie obiektów, zwłaszcza terenu zmienia się skokowo od zdecydowanie zbyt ciemnego, do właściwego.
I zauważyłem dziwne zachowanie, jak jechałem ED72 zapalanie świateł zarówno w kabinie, jak i zewnętrznych reflektorów było możliwe przy opuszczonych patykach i wyłączonej baterii.
Aha, jeszcze jedno - coś chyba nie tak jest z wykolejaniem. Tak dla jaj za Jarkawkami rozbujałem się SN61 do 100km/h po ograniczeniach do 20, fajnie bo miotało pudłem jak szatan, ale wykoleić się nie chciał. No w końcu, na bardzo ostrym łuku coś tam się zrobiło, ale brakowało huku, po prostu jakiś taki dźwięk hamowania, zatrzymanie nie było bardzo nagłe, ruszyć się już nie dało, pod F2 "Damage status: OK", nie powinno być derailed? Aż sprawdzałem czy się da ruszyć, ale nie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 26 Lutego 2017, 08:06:16
Przeciez bylo napisane, ze oswietlane sa cale trojkaty, stad ta skokowa zmiana jasnosci. Nie jest to docelowe oswietlenie, prace sie nie zakonczyly. Co do reszty, potwierdze jak sam sprawdze.
ED:
Załącznik, mechanizm wykolejenia działa. Można zapytać czy prawidłową czułość ma, ale tu trzeba wielokrotnych powtórzeń i porównań ze starym exe. Nie można się wykoleić w trybie debug mode, ale tak było od zawsze i tak miało być. Nie potwierdzam możliwości włączenia lamp bez baterii w siódemce. Inne pojazdy do sprawdzenia.
ED2:
Załącznik 2 pokazuje włączenie smugi mimo braku załączenia baterii. Lampy są ciemne, te włączyć można tylko po włączeniu baterii. Należy smugę uzależnić od baterii.
ED3:
Jeszcze jedno derailed na ED72. Co do SN61 i Całkowa, całkiem możliwe, że tam nie ma wpisanych potrzebnych informacji do wykolejenia.

PS: Przy 1080*1920 nie można zrobić bardziej skompresowanego załącznika, aby coś jeszcze było widać z napisami. Celowe jest zwiększenie załącznika do 300kib.

@HTD, nie napisałeś w jakim trybie (debug mode, czy zwykły) jeździłeś. Nie podałeś na jakiej scenerii, ciężko potem potwierdzać lub zaprzeczać komunikatom. Podawanie warunków wystąpienia niepożądanych efektów zaoszczędza innym pracy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 26 Lutego 2017, 11:39:03
Przepraszam. Jechałem w trybie normalnym, na Zwierzyńcu, ED72, rano (wersja którą dawałem do testów). Nie próbowałem go wykolejać, przejechałem do końca, bo na starym exe ten scenariusz kończył się dokładnie jak zaczynało się robić jasno, chciałem porównać światło. Ogólnie jest dużo ciemniej (miałem problem w orientacji przy zapalonej tylko prawej lampie), ale trudno ocenić czy ogólna jasność jest prawidłowa, bo te trójkąty migają jak szalone, przez chwilę jest idealnie, za chwilę jest źle.

To, że oświetlenie jest dla całych trójkątów to wiem bo to widać. I tak wygląda 100x lepiej niż wszystko co było wcześniej. To jednak nie tłumaczy dlaczego ten sam trójkąt nagle robi się dużo jaśniejszy, i gwałtownie gaśnie. Wg mnie prawidłowy algorytm powinien uzależniać oświetlenie danego trójkąta od odległości od lampy - ta zmienia się płynnie. Tymczasem oświetlenie trójkątów zmienia się skokowo. Zgaduję, że do obliczeń brany jest nie ten trójkąt, tylko jakiś inny, który znajduje się za czołem składu. Skąd zgaduję? Zbliżam się do peronu, cały peron jest prawidłowo oświetlony. Nagle peron gaśnie, chociaż nie zdążyłem nawet minąć czołem składu jego początku. Nie narzekam, po prostu opisuję jak to się zachowuje w tej wersji.

Potem testowałem scenariusz Całkowo SN61, tryb normalny, tego wykolejałem, ale wykolejenie nie dało opisu "derailed" i w zasadzie nie było widać że skład był wykolejony. Po prostu dość szybko nagle zahamował i nie dało się ruszyć, po tym poznałem, że jednak się wykoleił.

Przy okazji dla SN-a testowałem też hamulec pomocniczy - nadal nie działa, ale z tego co wiem to nie było jeszcze poprawiane. Zrobiłem kilka screenów z jazd, ale nie wnoszą nic nowego do tematu więc nie wklejam.

Ciekawostka: ostre zahamowanie przechyla kamerę w pionie - bardzo fajny efekt, jakby się mechanik bujnął w fotelu ;) Niestety ten sam efekt występuje przy odhamowaniu kiedy skład się nie porusza, ani nie zaczyna się poruszać po odhamowaniu. OK, po odhamowaniu lokomotywa może się przemieścić względem składu nieznacznie i to powinno być odczuwalne w kabinie, mam jednak wrażenie, że tylko w przypadku używania hamulca pomocniczego, w przypadku zespolonego ten efekt powinien być pomijalny, zwłaszcza podczas odhamowania na postoju.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 26 Lutego 2017, 11:51:06
Nie sądzę, aby przy tej skali zmian w exe jaka mamy, można było od ręki poprawiać zjawiska fizyczne występujące w symulatorze. Sprawdził bym wykolejenie SN61 na normalnym "exe", wydaje mi się, że tam nie działało derailed. Co do świateł, nie miałem takich odczuć jak Ty, jadąc na Kaliskiej znikanie oświetlonych trójkątów jest strawne. Być może zależne jest to od wielkości trójkąta użytego do budowy terenu. Pamiętajmy, że to dopiero propozycja świateł.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 26 Lutego 2017, 11:59:21
Obecnie to się oblicza nie tyle co dla trójkątów, tylko dla wierzchołków. Jeżeli peron składa się z dwóch trójkątów, to świecenie na środku nie da nic, bo obliczenia robią się tylko na wierzchołkach a później są tylko interpolowane na resztę.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 26 Lutego 2017, 12:14:32
To jednak nie tłumaczy dlaczego ten sam trójkąt nagle robi się dużo jaśniejszy, i gwałtownie gaśnie.
To dlatego, ze tak jak napisal Milek oswietlenie jest kalkulowane na podstawie wierzcholkow -- wystarczy, ze jeden wierzcholek nie jest oswietlony, i nastepuje interpolacja od 'oswietlony' do 'ciemny' na calej powierzchni, a przy duzych trojkatach (a z takich zazwyczaj sklada sie teren i np proste perony) ma to miejsce bardzo czesto.

edit: co do ruchu kamery, ten jest robiony na podstawie obliczanego przez symulator przyspieszenia, a po odhamowaniu gdy sklad zaczyna ruszac to przyspieszenie jest kalkulowane jako dosc wysokie, ze wzgledu na zmiane predkosci z 0 do jakiejs tam, niewazne jak malej. Tu by sie musial fizyk pochylic :d
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 26 Lutego 2017, 12:55:50
Czy w ostatniej kompilacji jest poprawka na dwuliterowe nazwy? Zgłaszane przez Macieja.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 26 Lutego 2017, 13:03:00
Jeszcze nie, ale blad dotyczyl tylko ladowania .t3d, wiec jesli ladujesz pliki .e3d to sie nie objawia.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: queuedEU w 26 Lutego 2017, 13:41:05
Światła wyglądają faktycznie najlepiej, tylko 1 problem - oświetlenie obiektów, zwłaszcza terenu zmienia się skokowo od zdecydowanie zbyt ciemnego, do właściwego.
I zauważyłem dziwne zachowanie, jak jechałem ED72 zapalanie świateł zarówno w kabinie, jak i zewnętrznych reflektorów było możliwe przy opuszczonych patykach i wyłączonej baterii.
Aha, jeszcze jedno - coś chyba nie tak jest z wykolejaniem. Tak dla jaj za Jarkawkami rozbujałem się SN61 do 100km/h po ograniczeniach do 20, fajnie bo miotało pudłem jak szatan, ale wykoleić się nie chciał. No w końcu, na bardzo ostrym łuku coś tam się zrobiło, ale brakowało huku, po prostu jakiś taki dźwięk hamowania, zatrzymanie nie było bardzo nagłe, ruszyć się już nie dało, pod F2 "Damage status: OK", nie powinno być derailed? Aż sprawdzałem czy się da ruszyć, ale nie.
Te Oswietlaenie czola pociagu jest na standardowych OpenGLowych swiatlach, domyslam sie bo nie oswietla terenu z powodu braku odpowiedniej teselacji. Natomiast jezeli chodzi o ladne rozchodzenie sie swiatla na geometrii toru, to domyslam sie ze zwiekszyliscie segmentacje odcinkow i to pewnie jest powodem wykolejen w pewnych przypadkach. Az sie zaraz pochwale tym co od kilku dni mam gotowe. Problemy z wykolejaniem tez mialem ale wystarczylo pewna rzecz zmienic i jest dobrze. Ja do wprowadzenia tych spotlightow (zrobilem se wszystkie trzy) ustawilem segmentacje torow na 2m i nie zauwazylem duzego spadku FPS (na 053 jest ok na duzej stacji). Sie zastanawiam... Nagrac film czy tylko screenyy...
EDIT:
Filmik poproszę //Sawi

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 26 Lutego 2017, 16:40:52
Segmentacja nie powinna chyba wplywac na wykolejenia, bo jest tylko na poziomie generowania dodatkowych trojkatow dla wizualizacji (no i zmiana dotyczy odcinkow prostych, gdzie o wykolejenie trudno :)  Natomiast glowy nie dam ze wszystko jest w porzadku z sama procedura wykolejenie i/lub wyswietlanym stanem uszkodzen, bo nie zagladalem tam za bardzo.

W dzisiejszym uaktualnieniu w zasadzie tylko maintenance mode

- zmieniony nieco model kolorowania nieba, zolcie, roze itp pojawiaja sie dopiero gdy slonce zejdzie dostatecznie nisko, w ciagu dnia sa w zasadzie tylko biel/blekit, czyli bardziej jak w naturze

- wlaczona z powrotem obsluga chmur. Tutaj zwracam uwage, ze uzywany zazwyczaj sky_dynamic_stratus.t3d ma dodatkowe element jak slonce, ksiezyc i gwiazdy, ktore gryza sie wizualnie z tym co jest rysowane obecnie. Do .exe dolaczony jest model alternatywny, skydome_clouds.t3d ktory jest w duzym skrocie wersja sky_dynamic_stratus.t3d z wycietymi elementami dodatkowymi (czyli zostaja same chmury, a gwiazdy itp .exe i tak wyswietla/bedzie wyswietlac kiedy trzeba) Dodatkowo na kolor chmur (przynajmniej tych dynamic) ma tez wplyw biezace oswietlenie nieba, czyli nie wyglada to dokladnie tak samo jak przedtem, ale tez odrobine bardziej jak powinno, zwlaszcza w nocy

- dolaczone zmiany Macka001 dla MWD

- poprawki znalezionych bledow (niewyswietlanie niektorych sub-modeli przy ladowaniu .t3d, swiatla dzialajace bez wlaczonej baterii, moze cos tam jeszcze, czego nie pamietam
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 26 Lutego 2017, 17:37:01
Mozliwosc przyciemnienia dodawales? Czy odpusciles temat?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 26 Lutego 2017, 18:02:15
Przyciemnienia swiatel? Nie, siedzi sobie w kolejce rzeczy do zrobienia, zrobi sie jak bedzie funkcjonujacy przelacznik w kabinach, i sensowny klawisz zeby to podpiac. W kodzie znalazlem
    TGauge ggUpperLightButton;
    TGauge ggLeftLightButton;
    TGauge ggRightLightButton;
    TGauge ggLeftEndLightButton;
    TGauge ggRightEndLightButton;
    TGauge ggLightsButton; // przelacznik reflektorow (wszystkich)
    // hunter-230112: przelacznik swiatel tylnich
    TGauge ggRearUpperLightButton;
    TGauge ggRearLeftLightButton;
    TGauge ggRearRightLightButton;
    TGauge ggRearLeftEndLightButton;
    TGauge ggRearRightEndLightButton;
    TGauge ggCabLightButton; // hunter-091012: przelacznik oswietlania kabiny
    TGauge ggCabLightDimButton; // hunter-091012: przelacznik przyciemnienia
ale do przyciemniania swiatel zewnetrznych nic nie ma. Chyba ze ggLightsButton (lights_sw) ma to miec, ale on jest chyba uzywany do wyboru kombinacji stanu swiatel.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: queuedEU w 26 Lutego 2017, 18:04:35
Moze ja sie wypowiem na temat przyciemnienia prezetujac pseudokod.


 float dimf = 0;
  float a = 0;

  if (dimheadlights) dimf = 0.4f;

  if (k==1) SL->setlADS(0.9-dimf, 0.8-dimf, 0.7-dimf, 1.0,      0.7, 0.6, 0.7, 1.0,      0.7, 0.7, 0.7, 1.0);
  if (k==2) SL->setlADS(0.9-dimf, 0.8-dimf, 0.7-dimf, 1.0,      0.7, 0.6, 0.7, 1.0,      0.9, 0.8, 0.9, 1.0);

  if (Console::Pressed(VK_CONTROL) && (cKey == 'D')) dimheadlights = !dimheadlights;      // w OnKeyDown();


Jak widac tyle zejmuje dodanie tej opcji, nie uwzgledniajac dodania obslugi hebelka bo chyba nie ma ztcp.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 26 Lutego 2017, 18:34:36
No wlasnie o obsluge kontrolki sie rozchodzi :)  bo dodac klawisz i wspolczynnik dla sily swiatla to nie problem, ale wtedy na 100% wyskoczy sytuacja ze ktos wcisnie kombinacje, nawet nie zauwazy, ale bedzie problem ze swiatla nagle nie dosc jasne i nie wiadomo czemu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 26 Lutego 2017, 18:55:22
Wciskania klawiszy jakbym miał dość. Nie myślałem, że kiedyś to napiszę, ale takie bajery to może zostawić wskaźnikowi myszki i prawdziwej obsłudze przełączników.
Nadal pod F1 (debug mode) nie mam parametrów pozycji nastawnika, bocznikowania i ciśnień w PG, ZG i CH, zrozumiałe że nie widać napięcia w sieci i poboru prądu. Pozycja mechanika blokowana jest w czasie jazdy AI (po wciśnięciu shift+Q), światłą nie są 3 stopniowe, po prostu pojawiają się po wciśnięciu kolejnego klawisza. Trudniej było mi przejąć inny pojazd w biegu pod F5. Księżyc jest zarąbisty. Wciśnięcie alt+Q powoduje zapytanie o wyjście z symulacji. Tyle na gorąco.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 26 Lutego 2017, 19:12:14
Wciskania klawiszy jakbym miał dość. Nie myślałem, że kiedyś to napiszę, ale takie bajery to może zostawić wskaźnikowi myszki i prawdziwej obsłudze przełączników.
Jeśli mogę zaproponować, to [Shift] + [Ctrl] + [L] załączenie przyciemnienia i [Ctrl] + [L] wyłączenie przyciemnienia. "L" to w wielu grach światła (gdyby ktoś szukał skrótu po przypadkowym załączeniu przyciemnienia), do tego na klawiaturze jest obok oświetlenia i przyciemnienia oświetlenia kabiny oraz oświetlenia przyrządów, a przyda się osobom z pulpitami. Jedynie jeszcze do Readme doda się odpowiedni wpis. Poza tym świetne to oświetlenie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 26 Lutego 2017, 19:20:01
Build GLFW z zapisywaniem E3D niezależnym od układu obiektu w pamięci:
x32: https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng32-bd9cd6f7.zip
x64: https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng64-bd9cd6f7.zip
Teraz wreszcie można się zabrać za przerabianie dźwięku.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: joey w 26 Lutego 2017, 19:25:21
Ponawiam zgloszenie o niehamujacych przed przejazdami samochodach. Zglebiajac sie w szczegoly: dotyczy to pojazdow arosa, golf, ka, nie wiem jak innych; przed przejazdem samochod taki zaczyna hamowac, blokuja sie mu kola i na poslizgu przejezdza przez szlabany, po czym kontynuuje normalna jazde
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 26 Lutego 2017, 19:47:02
Nadal pod F1 (debug mode) nie mam parametrów pozycji nastawnika, bocznikowania i ciśnień w PG, ZG i CH, zrozumiałe że nie widać napięcia w sieci i poboru prądu.
Sprawdz jesli mozesz, czy faktycznie bylo to F1 nacisniety w debug mode, a nie w trybie zwyklym. Sprawdzajac u mnie, wyglada ze to dziala -- screen w zalaczniku, parametry podane sa tak jak byly zawsze, nic tam nie zmienialem.

Cytuj
światłą nie są 3 stopniowe, po prostu pojawiają się po wciśnięciu kolejnego klawisza.
Swiatla sa nadal 3-stopniowe, ale nalezy zwrocic uwage, ze przelaczniki swiatel mozna ustawic przy wylaczonej baterii. Czyli mozesz wlaczyc np swiatlo lewe i prawe i dopoki bateria jest nie zalaczona nie pojawi sie nic, a po wlaczeniu baterii aktywuja sie oba swiatla naraz. Natomiast jesli wlaczysz baterie najpierw, a nastepnie przelaczniki swiatel jeden po drugim, to swiatla powinny pojawic sie 3-stopniowo.

(piractwo drogowe zapewne ma cos wspolnego z zawartoscia plikow .fiz, ktos musialbys sprawdzic, czy sa tam jakies zauwazalne roznice w porownaniu do samochodow hamujacych poprawnie)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 26 Lutego 2017, 20:17:45
Może współczynnik mbf/masa. Blokują koła, a że lekkie są, to suną jak sanki. Już dawno miałem zrobić tor testowy dla samochodów i nadal nie mam nic. :(
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 26 Lutego 2017, 20:33:07
Znalazły się napisy pod F1, sorki, jakoś się źle musiało uruchomić. ;) (Kropka przed emotikonem wygląda okropnie.)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: queuedEU w 26 Lutego 2017, 21:15:24
@Milek, jezeli chodzi o GLFW to rozumie ze na razie zrobiles tylko inicjalizacje na jego funkcjach, jako tako w kodzie reszty jescze nie pozamieinales?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 26 Lutego 2017, 21:16:55
No tworzenie okienek, kontekstu opengl i sterowanie jest przeniesione.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: queuedEU w 26 Lutego 2017, 21:29:26
Czyli praktycznie od teraz juz jest mozliwosc wdrazania nieskonczonej ilosci ficzerow opartych na shaderach i ogolnie na nowych technologiach, ktore dostepne sa w tutkach na internetach :).
Super, dobra robota men :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 26 Lutego 2017, 21:33:19
Brawo. Teraz wrzućcie wszystko na mastera by było w jednym branchu i z czystym sumieniem devsa przyznam. :)

@tmj, bardzo podoba mi się nowy wireframe. Idealny do testów modeli dla ludzi bez maxa.
Jeden reflektor ledwo co daje, trzy mam wrażenie oświetlają skyboxa nawet, a na pewno las kilkaset metrów przed lokiem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 26 Lutego 2017, 21:48:02
Milek7, Twoja kompilacje odpale jutro, dzis nie dam juz rady a szkoda, bo zapowiada sie apetycznie. Powinienem skonczyc tez z XP bo ledwo dyszy. 
Tmj, w Twojej kompilacji lacznie ze swiatelkami jest ok. Musialo mnie przymulic przy pierwszym otwarciu. To co, za miesiac mamy nowe exe? No moze dwa. ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 26 Lutego 2017, 22:04:41
@tmj: coś się zepsuło przy mergowaniu, czy te światła zapomniałeś wrzucić na githuba?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 26 Lutego 2017, 22:33:50
Jeszcze nie wrzucilem, bo ogarniam najpierw zeby swiecilo cos wiecej niz tylko prowadzony pojazd, chwile to zajmie :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 26 Lutego 2017, 22:51:01
Witam, takie coś mi się pojawia podczas uruchomienia. Mógłby mi ktoś powiedzieć co jest nie tak? Zauważyłem, że jeśli podmienię pliki na te od Milka w sensie pliki .dll to nie odpala wcale .exe 170226.

Edit. Natomiast jeśli pobiorę glew32.dll do którego link jest w pierwszym poście, to exe wyrzuca błąd jeszcze przed uruchomieniem konsoli i wyskakuje, że aplikacja nie może zostać uruchomiona.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 26 Lutego 2017, 23:02:02
A moje exe odpala? Dllek nie mieszać bo chyba jest inna wersja glew.

Kończy się miejsce na partycji, i tak sobie pomyślałem, co wy na zastosowanie kompresji do .e3d i .dds? Skompresowane zlibem dds zajmują prawie 3x mniej, a e3d nawet 5x. Na pewno sporo się zyska na wielkości paczki, a szybkość wczytywania to będzie zależeć od szybkości dekompresji i dysku, ale myślę że możliwe będzie żeby było szybciej, szczególnie na talerzowych.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 26 Lutego 2017, 23:13:05
I tak wszystko ładuje na starcie, wiec nie ma przeciwwskazań. Ale chciałbym mieć exeka na masterze z dopieszczonymi wszystkimi ficzerami co są i dodanym nowym skanowaniem od Firleja. Trzeba by na wiosnę paczkę wydać, a ten vertex shader średnio się dla ludzi nadaje niestety.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 26 Lutego 2017, 23:13:51
Problem rozwiązany, usunąłem stare sky_stars.e3d
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 26 Lutego 2017, 23:21:25
Ja testuje na dwie paczki, nawet nie probowalem wrzucac do jednego worka. Co do kompresowania e3d i dds, nikt nie wpadl na ten pomysl wczesniej? Trzeba poszukac na forum czy byly takie plany. Moim zdaniem nie warto kpnmpresowac i robic problemy dodatkowym obciazeniem. Dyski sa tanie i nie ma co oszczedzac.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 27 Lutego 2017, 03:46:32
OK, w nowym uaktualnieniu mamy swiatla przydzielane dynamicznie do pojazdow na podstawie odleglosci do kamery i/lub ilosci zapalonych lamp. Ilosc obslugiwanych swiatel jest kontrolowana wpisem w .ini
dynamiclights ilosc
wartoscia domyslna jest 3 (bo z tego co pamietam starsze karty moga miec klopoty z obsluga wiecej niz 4 swiatel, a jedno swiatlo jest uzyte dla oswietlenia ogolnego). Co powinno wystarczyc dla prowadzonego pociagu i 1-2 mijanych skladow. Maksymalna wartoscia jest 7, bo 8 swiatel to wymagane specyfikacja minimum i wiekszosc sterownikow nie obsluguje wiecej. Sprawdzilem z ciekawosci calkowo_niebezpieczny_pociag z ustawieniem 7 swiatel i liczylo sie to spokojnie, ale nie znaczy, ze u kazdego tak bedzie.

aha, co do zasiegu swiatel, to sa one w tej chwili ustawione na szerokosc 20 stopni od osi i faktycznie dosc daleki zasieg, bo nie wiem jak to jest w lokomotywie, a po narzekaniach ze jest za ciemno uznalem ze bezpieczniej juz przesadzic w druga strone :d  Jesli ma ktos jakies prawdziwe dane jak to wyglada w naturze, to prosze mowic.

edit: nie sprawdzilem i wyszlo dopiero po publikacji, ale jest idiotyczne nieszczescie z kiblem, ktory w symulatorze po wlaczeniu swiatel w kabinie "wlacza" je sobie we wszyskich trzech segmentach, mimo tego ze dwa z nich nie maja zadnych swiatel zainstalowanych na tym koncu. gg. O ile sie orientuje to w .fix/.mmd nie ma zadnych wpisow czy swiatla w ogole istnieja, wiec rozplatac to bedzie raczej trudno. Podejrzewam ze to samo wystapi w lokomotywach dwuczlonowych :|
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: adamst w 27 Lutego 2017, 07:44:20
Proponowałbym uzależnić zapalanie świateł w pojeździe od obecności w nim maszynisty. To powinno w miarę sprawnie obejść problem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 27 Lutego 2017, 10:47:51
@Milek7, odpaliłem Twoje exe bez problemu. Zaliczyłem TD i jakąś misję na Bałtyku. Jedyne co znalazłem, to w kabinie A siódemki przezroczystość po zapaleniu lampki SHP. W kabinie B zapalenie lampki jest ok. Nie wiem czy efekt jest uboczny, ale jak używam alt+tab mogę przełączać okna i pisać w oknie notatnika lub czatu jednocześnie obserwując symulację. Mogę też robić screeny jak na załączniku 2. Niestety teraz w Twoim exe symulacja zwijana jest z ekranu. Musi tak zostać?
@tmj, efekty oświetleniowe super, nowy rozdział symulatora. Oczywiście w takim stanie pozostawiają niedosyt, ale kierunek jest właściwy. Moim zdaniem wiązka wygląda na szerszą niż 20 stopni. Jak powinna wyglądać nie mam pojęcia i czas pewnie wybrać się na szlak z aparatem po ciemku.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 27 Lutego 2017, 11:26:03
Jaka to dokładnie lokomotywa z tą przeźroczystością? E3D z paczki, czy T3D, czy wygenerowane E3D?

Z alt+tab mówisz o trybie pełnoekranowym, tak? Mogę sprawdzić czy wyłączenie GLFW_AUTO_ICONIFY to zmieni, ale właściwie to tak jest lepiej?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 27 Lutego 2017, 11:44:38
Paczka TGA, lokomotywa EP08-006. E3D musialo sie wygenerowac wczesniej, to nie bylo pierwsze uruchomienie tej scenerii. Z alt+tab w trybie pelnoekranowym. Tutaj wolalbym, aby nie zwijalo symulacji z ekranu. Przynajmniej w debug mode, jesli sie da. Jak pisalem, przy obserwacji symulacji byla mozliwosc otwarcia malego aktywnego okna, chocby czatu, jednoczesnie widzac co dzieje sie w tle. Ta EP08 moge jeszcze raz wygenerowac, jesli to sie przyda.
ED:
Na dzisiejszym exe od @tmj, nie mam tej przezroczystości. Spróbuję powtórzyć na Twoim.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Sawi w 27 Lutego 2017, 12:03:08
Jeśli nie było wprowadzanych żadnych zmian do modelu świni, to nie ma sensu od nowa generować tego pliku.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 27 Lutego 2017, 12:03:33
Już mam u siebie, zepsute jest na E3D. Zaraz to poprawię.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: maciek001 w 27 Lutego 2017, 12:22:49
Panowie będę miał prośbę. Możecie dodać przyciemnianie reflektorów? Na razie może być bez przycisku na klawiaturze - wystarczy sama metoda. Może wystarczy zdefiniowanie gdzieś jasności po przyciemnieniu i zrobienie Dim-a z boolem :) widzi się to komuś?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 27 Lutego 2017, 12:28:56
Jeśli nie było wprowadzanych żadnych zmian do modelu świni, to nie ma sensu od nowa generować tego pliku.
E3d były generowane innym starszym exe od tmj, stąd sprawdzenie powtórne na exe od Milek7. Natomiast chętnie poznam przyczynę dla której w kabinie B, było ok.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 27 Lutego 2017, 12:35:43
Też jest źle. Pewnie na A miałeś już wygenerowane i wczytało E3D, a na B wczytało się T3D i dopiero się generowało.

Coś jest namieszane z Opacity, bo w kodzie z tym "float Opacity; // nie używane, ale wczytywane" to w ogóle jakieś cuda na kiju są.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 27 Lutego 2017, 12:38:55
No i po wywaleniu starych e3d z katalogu EP08, wygenerowało się powtórnie i poprawnie na Twojej kompilacji. W sumie z mojej strony po temacie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 27 Lutego 2017, 12:43:32
Czekaj, jak poprawnie? Wychodzi mi że na T3D jest ok, a E3D źle, niezależnie od tego na czym było generowane. Pamiętaj że jak się generują e3d to użyte będą dopiero przy następnym uruchomieniu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 27 Lutego 2017, 13:26:55
Poprawiłem, wystarczyło usunąć kilka linijek. Ten bug był już wcześniej, tylko się nie ujawniał. Na próbę wyłączyłem auto iconify i zmergowałem to co tmj wrzucił na githuba.
32b: https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng32-e3df71c0.zip
64b: https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng64-e3df71c0.zip

@tmj: tak btw to brakuje notki licencyjnej MPL2 w niektórych plikach które dodałeś
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 27 Lutego 2017, 13:31:30
Proponowałbym uzależnić zapalanie świateł w pojeździe od obecności w nim maszynisty. To powinno w miarę sprawnie obejść problem.
Mniej wiecej na tym sie na dana chwile skonczylo -- dodalem test na pojazdy, ktora sa ustawione jako "AIdriver" ale bez przydzielonego kontrolera AI, I wyglada na to, ze dziala (takze dla ET41 i innych dziwnych kombinacji)  Caly problem wzial sie stad, ze pojazdy nie przechowuja zawsze wlasnego stanu swiatel, ale czasami sa konfigurowane by kopiowac stan czlonu prowadzacego. Czemu, przyrodzenie raczy wiedziec :x

edit:
@tmj: tak btw to brakuje notki licencyjnej MPL2 w niektórych plikach które dodałeś
Ja do takich glupot glowy nie mam :)  Cos sie chyba nie calkiem polaczylo, bo sprawdzajac na szybko to swiatla nie dzialaja w ogole.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: dymus w 27 Lutego 2017, 13:50:21
To dotyczy poprzednich exe c++, ale brakuje dźwięków falowników.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 27 Lutego 2017, 14:04:34
Zgubiłem init gfxrenderer :p
32b: https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng32-82109b03.zip
64b: https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng64-82109b03.zip
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: ST44-003 w 27 Lutego 2017, 14:13:37
Ja mam jedno pytanko, ale zaznaczam, nie testowałem tego drugi raz, więc może po poprawce się to zmieniło.
Wczoraj testowałem Bałtyk_IR na ET22. Od momentu załączenia symulacji aż do jej wyłączenia cały czas był słyszalny syk hamulca. Dźwięk luzowania hamulca, bardzo głośny z resztą. Powód mi jest nie znany.
Natomiast sprawdzając chwilę po tym skład fabrycznie wstawiony na TD tego problemu już nie było.

Chcę też zapytać, jak to jest z przejściem tego oświetlenia w inny rejon. Smuga nie przechodzi płynnie po drzewach, słupach czy terenie, tylko skacze, aczkolwiek poruszając się delikatnie płynnie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 27 Lutego 2017, 14:40:48
Chcę też zapytać, jak to jest z przejściem tego oświetlenia w inny rejon. Smuga nie przechodzi płynnie po drzewach, słupach czy terenie, tylko skacze, aczkolwiek poruszając się delikatnie płynnie.
Powodem tutaj jest stosowany model oswietlenia -- "stary" openGL oblicza sobie swiatlo dla wierzcholkow bryl umieszczonych w scenie, wiec rozklad i 'skoki' w oswietleniu zaleza glownie od tego ile tych wierzcholkow wystepuje w danym modelu. Roznice miedzy tym modelem, a bardziej dokladnym oswietleniem liczonym osobno dla kazdego piksela dosc dobrze widac na tym przykladzie:


Poniewaz duza czesc obiektow w symulatorze (drzewa, ploty, itp) opiera sie na maksymalnie uproszczonych plaszczyznach z 2-4 trojkatow na krzyz, zmiany jasnosci sa bardzo wyrazne. Raczej nie da sie tutaj nic zrobic do czasu odlaczenia/przebudowy silnika graficznego. Tzn mozna by sie bawic w reczny podzial bryl i inne takie, ale to raczej marnowanie czasu.

To dotyczy poprzednich exe c++, ale brakuje dźwięków falowników.
Jakbym wiedzial co to falownik i jak to powinno brzmiec, to byloby latwiej ;/ do syczenia w lokomotywach to specjalistow trzeba, niestety.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 27 Lutego 2017, 15:29:48
Czekaj, jak poprawnie? Wychodzi mi że na T3D jest ok, a E3D źle, niezależnie od tego na czym było generowane. Pamiętaj że jak się generują e3d to użyte będą dopiero przy następnym uruchomieniu.
Twoje exe uruchomiłem na paczce t3d/tga. Jednak plik e3d istniejący w katalogu z lokiem był wygenerowany jakiś czas temu przez inne exe. Zakładam, że przez którąś poprzednią z Twoich kompilacji. Ponieważ błąd z lampką pojawił się w jednej kabinie, uznałem, że wygeneruję jeszcze raz e3d, w tym celu usunąłem podejrzane pliki  i uruchomiłem jeszcze raz symulację. Tym razem, Twoje exe spreparowało poprawny plik e3d, czyli ustąpiła przezroczystość lampki. Mam nadzieję, że zrozumiale wytłumaczyłem, może za wcześnie podniosłem alarm. Jednak warto zwracać uwagę na takie rzeczy.
Wywalił mi się monitor, stąd długie poszukiwanie jakiegoś zamiennika i brak odpowiedzi z mojej strony.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 27 Lutego 2017, 15:40:37
Bug już poprawiony w ostatniej wersji, ale w kwestii wyjaśnienia: po skasowaniu e3d i uruchomieniu, wczytują się t3d i dopiero zapisują nowe e3d. Zostaną one użyte dopiero przy następnym uruchomieniu. Raczej więc niemożliwe żeby na tamtym buildzie załadowała się dobra przeźroczystość z e3d. Ale to już nieistotne.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 27 Lutego 2017, 15:58:17
Przyznam, że tego nie wiedziałem. Myślałem, że jeśli generuje przy uruchamianiu e3d, to są one używane do wyświetlania modeli.
Coś jednak zepsułeś, 3 uruchomienia, nie działa F1. Alt+tab kompletnie pomieszany, lepiej wrócić do tego co było, straciłem kontrolę co ma być na wierzchu w oknie.
ED:
Wygląda na to, jakbyś dawno nie używał windowsa, zostaw to może jak było. Kompilacja tmj przełącza się bardzo ładnie między oknami aplikacji. Choć jeszcze muszę sprawdzić tą po południową.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: dymus w 27 Lutego 2017, 16:48:04
Cytuj
Jakbym wiedzial co to falownik i jak to powinno brzmiec, to byloby latwiej ;/
Dźwięk z sekcji sounds, ventilator:  w pliku mmd ;) Ogólnie ventilator odpowiada za wentylatory oporów tam gdzie są opory rozruchowe, ale przy asynchronicznych u nas odpowiada to za dźwięk właśnie falownika.
A falownik reguluje napięcie i częstotliwość które jest podawane na silniki asynchroniczne.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: fuji8 w 27 Lutego 2017, 17:24:39
Zgłaszam że exe na radeonie nie hula, zamiast smugi, po prostu podświetla mi całą scenerię. Załączam tylko crashdumpa ponieważ loga wogóle nie chce mi zapisać.zrobiłem to inaczej i załączam także log.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 27 Lutego 2017, 17:36:06
Podrzuc jesli mozesz log, obojetnie z jakiej sceny, moze byc TD.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: ST44-003 w 27 Lutego 2017, 17:45:59
@tmj, rozumiem, że exe odczytuje datę z systemu i do niej dobiera wysokość słońca? Dałoby się może to przenieść do ręcznej zmiany daty i godziny? Tak jak to ma miejsce np. w OMSI? Jesteśmy na tą chwile uzależnieni od daty i godziny systemowej, a czasem chciałbym sobie sam dobrać godzinę do warunków na scenerii ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 27 Lutego 2017, 17:54:24
Przywróciłem auto iconify tak jak było i poprawiłem F1.
Ktoś robi dziwne konstrukcje rodzaju false == Console::Pressed( VK_CONTROL ) i przeoczyłem negację.

https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng32-5a8c158d.zip
https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng64-5a8c158d.zip
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 27 Lutego 2017, 18:19:28
@tmj, rozumiem, że exe odczytuje datę z systemu i do niej dobiera wysokość słońca? Dałoby się może to przenieść do ręcznej zmiany daty i godziny? Tak jak to ma miejsce np. w OMSI? Jesteśmy na tą chwile uzależnieni od daty i godziny systemowej, a czasem chciałbym sobie sam dobrać godzinę do warunków na scenerii ;)
Nie jestes uzalezniony, systemowa data jest pobierana przy ustawieniu dla scenerii parametru movelight 0 ale zamiast 0 mozesz podac liczbe od 1-365, ktora wymusi ustawienie na konkretny dzien roku :)  a godzina jest podobnie definiowana w scenariuszu. W debug mode mozesz uzyc shift+F1/ctrl+F1 zeby przesunac zegar o 5/20 minut naprzod, zeby latwiej znalezc dobrze wygladajacy czas.

edit:
Ktoś robi dziwne konstrukcje rodzaju false == Console::Pressed( VK_CONTROL ) i przeoczyłem negację.
Spedzisz dosc czasu wylapujac glupie bledy w stylu foo = false zamiast foo == false to tez bedziesz robil dziwne konstrukcje ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 27 Lutego 2017, 18:25:41
Milek7, sprawdziłem. Mam pod F1 co trzeba. Z tym przełączaniem aktywnych okien (alt+tab), skonsultuj z tmj.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 27 Lutego 2017, 18:33:17
Zgłaszam że exe na radeonie nie hula, zamiast smugi, po prostu podświetla mi całą scenerię. Załączam tylko crashdumpa ponieważ loga wogóle nie chce mi zapisać.zrobiłem to inaczej i załączam także log.
Z tego logu to wynika, ze tobie sie exe uruchamia nie na Radeonie, a na systemowej grafice Intela:
Renderer:
Intel(R) HD Graphics 4400
Vendor:
Intel
OpenGL Version:
4.3.0 - Build 10.18.14.4264
Czy Intel sobie poradzi to nie wiem (chociaz powinien), ale jak masz w systemie karte ATI, to warto moze wylaczyc w BIOS Intel Graphics czy jak to sie tam nazywa. Powinno byc jakies ustawienie, ze preferowana jest grafika na PCI Express, albo cos.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 27 Lutego 2017, 18:45:38
Jak to laptop to może trzeba po prostu w ustawieniach sterownika wybrać exe i wybrać kartę na której ma się uruchamiać.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: fuji8 w 27 Lutego 2017, 19:10:56
Dokładnie tak jak napisał @Miłek, wystarczyło przełączyć kartę graficzną, wszystko już działa. :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 27 Lutego 2017, 19:15:30
OK, glupie pytanie z innej beczki, dla specjalistow od hamulcow. W pliku .fiz dla 3e3-zez (wariant ET21) jest taki zapis:
BrakeValve=K
problem w tym, ze ten wariant nie jest praktycznie w ogole obslugiwany w kodzie, takze w wersji pascalowej. I w rezultacie hamulec lokomotywy nie dziala. Pytanie: czy mozna traktowac typ K tak samo jak typ W, biorac pod uwage ze w obu wypadkach w lokomotywie instalowany jest dokladnie ten sam obiekt hamulca (TWest)?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: youBy w 27 Lutego 2017, 19:21:20
Póki co tak, może kiedyś doczekamy się oddzielnej implementacji dla zaworu K. Funkcjonalnie jest zbliżony do W, więc nie zakłamujemy rzeczywistości za bardzo :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 27 Lutego 2017, 19:50:03
Ta wersja et jak i mod4 maja oerlikona przynajmniej krany. A co znaczy to W?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 27 Lutego 2017, 19:53:16
Hamulec Westinghouse (https://en.wikipedia.org/wiki/Railway_air_brake#Westinghouse_air_brake) o ile dobrze czytam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: szogun w 27 Lutego 2017, 21:19:40
Manewrowo, wysyp przy ładowaniu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 27 Lutego 2017, 21:22:03
Kaliskiej od 19-stej nie mogę uruchomić. Wywala albo zaraz po wejściu do loka albo w momencie wcisniecia f5. Zdaza się tez ze mrugają mi chmury na tym nowym modelu nieba. A czasami nie mrugają.

http://eu07.pl/userfiles/212/priv-migajace-niebo.rar

Mam dość dobranoc.

Na tym exe nie da się nawet kaliskiej zacząć chyba ze jako wolny obserwator to może tak.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 27 Lutego 2017, 21:34:33
@EP, cos tam nie tak poszlo, pliki w tym archiwum maja wielkosc 0 bajtow. Na dysku u ciebie tez takie sa?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 27 Lutego 2017, 21:35:20
Mam wysyp na Quarku, paczka dds. W logu różne zapisy na końcu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: szogun w 27 Lutego 2017, 21:40:06
Światła - zajefajne jak mamy dwa reflektory zapalone, ale na trzech to chyba trochę zbyt wiele :D No i jak się wjedzie w światła innego pojazdu to oświetla kabinę.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 27 Lutego 2017, 21:50:32
Jeśli będą liczone piksele, nie wierzchołki trójkątów, to światła powinny być ok. Tam gdzie trójkąty nie są pobudzone do świecenie (nie ma ich), albo są zbyt małe aby to zauważyć, jest nieźle.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 27 Lutego 2017, 21:55:29
Manewrowo, wysyp przy ładowaniu.
Skopany jest plik "dynamic/db/rlmmp_v1/gray.dds" ma wewnetrznie wielkosc 0 i nawet Photoshop nie potrafi tego odczytac. Po nadpisaniu poprawna wersja uruchamia sie normalnie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: szogun w 27 Lutego 2017, 21:58:10
https://youtu.be/j0W0A6QVh5I
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 27 Lutego 2017, 22:08:19
@EP, cos tam nie tak poszlo, pliki w tym archiwum maja wielkosc 0 bajtow. Na dysku u ciebie tez takie sa?

Tak tez mam takie. Widocznie tak zrobilo. Nie ingerowalem w to.

Krzysiek troche ci zazdroszcze ze to exe nie sprawia ci tylu problemow co mi. A moze to exe nie lubi systemu x64? Sam niewiem. Na td jest ok nawet pyton sie laduje ale td jest mala scn. Na kaliskiej gdzie scn duzo wazy o zapewnia duze mozliwosci juz sa kwiatki i pyton na tym samym loku nie dziala. W jezdzie jako pasazer nie da sie klawiszami ani podniesc okna ani otworzyc drzwi przedzialu a proba zabawy oswietleniem skutkuje wysypem. Ogolnie poza ladnym niebem i naprawde kozackimi smugami to tp exe jest niezwykle niestabilne i nieprzewidywalne, krasze niewiadomo z czego. Chodz linie546 na tym exe zaliczylem. Ale kaliskiej gdzie w gre wchodza przrsiadki i zmiany kabin nawet nie wystartuje ze stacji na wlokniarzu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 27 Lutego 2017, 22:21:10
Tak tez mam takie. Widocznie tak zrobilo. Nie ingerowalem w to.
OK, ten jeden ktory jest sensownej dlugosci pokazuje, ze wylecialo na probie odegrania nieistniejacego dzwieku, po wywolaniu kombinacji Ctrl+Universal4. Czyli najprawdopodobniej jest bledny zapis w pliku .mmd, albo brakujacy plik .wav albo inna cholera. Ktoregos dnia trzeba bedzie to poprawic kod, zeby przestalo na slepo probowac odtwarzac cos, czego nie ma. A w miedzyczasie kierowac uwagi o niekompletnym contencie do jego tworcow ;s

Mam wysyp na Quarku, paczka dds. W logu różne zapisy na końcu.
Obawiam sie, ze Quark laduje sie u mnie bez wysypu ;/ ale ten komunikat to mi wyglada na jakis klopot z bibliotekami VC runtime. Sprobuj pobrac instalke z https://www.microsoft.com/en-us/download/details.aspx?id=40784 i zobacz, czy cos pomoze.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 27 Lutego 2017, 22:24:28
Ale log starego exe nie pokazuje braku dzwieku. Ani w loku ani w wagonie. Czyzby stare exe to olewalo?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 27 Lutego 2017, 22:30:43
Ale log starego exe nie pokazuje braku dzwieku. Ani w loku ani w wagonie. Czyzby stare exe to olewalo?
Nie mam zielonego pojecia, mozliwe ze jest tam jakas roznica w ladowaniu plikow, ktora wylazla akurat przy tym czyms, czym probujesz jezdzic jako pasazer. I stare exe albo sobie radzi, albo olewa. Bez mozliwosci zaladowania tego u siebie nie mam jak sprawdzic, w zasadzie testy robie tylko na zawartosci paczki standardowej + kaliska + calkowo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 27 Lutego 2017, 22:42:41
Obawiam sie, ze Quark laduje sie u mnie bez wysypu ;/ ale ten komunikat to mi wyglada na jakis klopot z bibliotekami VC runtime. Sprobuj pobrac instalke z https://www.microsoft.com/en-us/download/details.aspx?id=40784 (https://www.microsoft.com/en-us/download/details.aspx?id=40784) i zobacz, czy cos pomoze.
Ładuje się za każdym razem, ale wysyp jest po 2 do 10 minut. Biblioteki instalowałem, ale może coś źle poszło. Na którymś z poprzednich exe było ok. Ale to muszę wrócić i sprawdzić
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 27 Lutego 2017, 22:58:00
Widzę po logach że niektórzy mają jeszcze opengl 2.0, więc póki co gl3 odpada przy modernizacji silnika.

BTW: ma ktoś cpu intela z architekturą skylake lub nowszą?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 27 Lutego 2017, 23:05:32
Ładuje się za każdym razem, ale wysyp jest po 2 do 10 minut.
Aha ok, uruchomie u siebie i zobacze, jak mu pojdzie. To jest przy jezdzie kiblem 2040, czy czyms innym? Czy bez roznicy?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 27 Lutego 2017, 23:18:30
Kiblem 2040, zwykle wysyp jest chwile po odjezdzie tego kibla po prawej. Raz udalo mi sie kawalek ujechac.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 27 Lutego 2017, 23:32:18
Kiblem 2040, zwykle wysyp jest chwile po odjezdzie tego kibla po prawej. Raz udalo mi sie kawalek ujechac.
Hmm no to raczej u mnie tego nie ma. Kibel z prawej pojechal, a 2040 na autopilocie jedzie jak profesjonalista, na zegarku symulatora 5:03 i idzie dalej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 27 Lutego 2017, 23:34:24
Ok, szukam u siebie. Wiem ze na pewno dzialala ta sceneria. Dzieki

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 28 Lutego 2017, 07:30:06
EN57: załączanie świateł zewnętrznych oświetla wnętrze kabiny nieprawidłowo. Uwaga: na wszystkich zdjęciach rzeczywiste oświetlenie kabiny jest wyłączone.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 28 Lutego 2017, 07:32:38
EN57: oświetlenie składu i scenerii od zewnątrz działa nieprawidłowo. Na zdjęciach odpowiednio włączone 0, 1, 2 i 3 reflektory. Skład wydaje się oświetlony od zewnątrz swoimi własnymi przednimi reflektorami.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 28 Lutego 2017, 07:47:52
Przywróciłem auto iconify tak jak było i poprawiłem F1.
Ktoś robi dziwne konstrukcje rodzaju false == Console::Pressed( VK_CONTROL ) i przeoczyłem negację.

https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng32-5a8c158d.zip
https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng64-5a8c158d.zip

Nie za bardzo poprawione. Nie da się wyłączać OSD, kolejne naciskanie F1 nic nie daje. Tak samo kolejne naciśnięcie F3 nie powoduje ukrycia rozkładu jazdy. Nie działa ESC dla wyłączenia pauzy w trybie normalnym. W trybie pełnoekranowym nie mogę wyświetlić innego okna na oknie ładowania, na wcześniejszych exe (tych od tmj) mogłem.

W poprzednich wersjach (do eu07++170227.exe) wyświetlanie okna programu (i konsoli) działało prawidłowo. Prawidłowo były także obsługiwane klawisze. Szczególnie przydatna była możliwość podglądu okna konsoli nałożonego na ekran ładowania (ten z notesem) na tym samym monitorze. Proponowałbym wprowadzenie alternatywnego ekranu ładowania, gdzie podczas całego procesu ładowania wyświetlana jest konsola. Chodzi mi o połączenie tych 2 rzeczy. Tzn konsolę graficzną: komunikaty w czasie rzeczywistym rysowane są w prostokącie ekranu głównego okna. Sam obrazek można dostosować, żeby zamiast małego notatniczka pokazywał się jakiś większy obiekt zajmujący większość ekranu. Niech będzie to przykładowo zdjęcie wyświetlacza z Traxx-a, gdzie ekran zajmuje większość wysokości okna. Dlaczego tak? Ekran ładowania jest bardzo statyczny, jest wyświetlany długo i wyświetla błędne informacje. W momencie kiedy pokazuje "ładowanie tekstur...OK" tekstury dopiero zaczęły się ładować i ładują się praktycznie przez cały czas do momentu wyświetlenia komunikatu "przygotowanie kabiny" (ten akurat pokazuje się we właściwym momencie).

Oprócz tego: bardzo przydatna będzie także możliwość wyłączenia nowego modelu oświetlenia w ini.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: ST44-003 w 28 Lutego 2017, 08:28:34
Jak masz grafikę Radeona, to niestety tak będzie. Radek sobie nie radzi z tym nowym ficzerem :(
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 28 Lutego 2017, 09:09:01
Jeśli coś działa na NVidii a nie działa na Radeonie - IMHO bug (nieprawidłowa, niekompatybilna implementacja).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: ST44-003 w 28 Lutego 2017, 09:19:03
Na razie ta wersja exe jest na etapie rozwoju. Ale zmierza w dobrą stronę, więc myślę, że szybko sobie z tym poradzą :D
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 28 Lutego 2017, 09:35:37
Z niedziałaniem świateł na radeonie, to bullshit. Jedyne co na radkach powszechnie nie działa, to napisy na ekranie ładowania.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 28 Lutego 2017, 10:47:15
Nowego skanowania w najbliższym czasie się nie spodziewajcie bo mam dłuższą przerwę w pracach. Miałem tygodniową delegację a teraz mam parę projektów do zrobienia do końca tygodnia a potem trzeba dom wiosennie ogarnąć więc dopóki się nie zrobi luźniej to do tematu nie wrócę.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 28 Lutego 2017, 11:33:38
Strasznie dziwna sprawa z tymi wysypami. Exeki z dnia 26 i 27 lutego nie wysypują się na Quarku, natomiast na 170227b wysyp był raz za razem. Próba doinstalowania bibliotek nic nie zmieniła w tej materii. Odpaliłem scenerię jeszcze raz na 170226 zakończyłem jazdę sukcesem, odpaliłem na 170227 - dotarłem do celu bez żadnych problemów. odpaliłem po raz kolejny na 170227b i... tym razem dojechałem do celu bez wysypu. Co najmniej dziwne. Usunę jeszcze plik $.scn, jeśli powtórzę dojazd do celu, będą musiał uznać że wysypy minęły. Jednak jest małe co nieco. W EN57-2040 na 170227b, nie odtwarza się dźwięk gwizdka, dokładnie to: 2000_odjazd.wavNa poprzednich exe do 170227 włącznie, gwizdek jest.
PS: Nie daje rady zainstalować bibliotek MS na win7, wyskakuje nieznany błąd opisany w sieci. Póki co, wersja 64 bitowa i odpalanie Maszyny na win7 w exe_c++, mogę zapomnieć.
Jeśli ktoś miał podobny problem i go rozwiązał, proszę o info na PW.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 28 Lutego 2017, 13:39:37
EN57: oświetlenie składu i scenerii od zewnątrz działa nieprawidłowo. Na zdjęciach odpowiednio włączone 0, 1, 2 i 3 reflektory. Skład wydaje się oświetlony od zewnątrz swoimi własnymi przednimi reflektorami.
Ktora to wersja exe? Ten blad byl w 170227, powinien byc usuniety w 170227b

Jak masz grafikę Radeona, to niestety tak będzie. Radek sobie nie radzi z tym nowym ficzerem :(
Pierwsze slysze, ma ktos Radeona, na ktorym to nie dziala? Jednej osobie wydawalo sie, ze jego Radeon sobie nie radzi, ale okazalo sie, ze to byla wbudowana karta Intela, a jego Radeon nie byl wlaczony, I po wlaczeniu wszystko poszlo.

Jednak jest małe co nieco. W EN57-2040 na 170227b, nie odtwarza się dźwięk gwizdka, dokładnie to: 2000_odjazd.wavNa poprzednich exe do 170227 włącznie, gwizdek jest.
PS: Nie daje rady zainstalować bibliotek MS na win7, wyskakuje nieznany błąd opisany w sieci. Póki co, wersja 64 bitowa i odpalanie Maszyny na win7 w exe_c++, mogę zapomnieć.
Jeśli ktoś miał podobny problem i go rozwiązał, proszę o info na PW.
Brak gwizdka w 170227b brzmi co najmniej dziwnie, bo ta wersja jest identyczna z poprzednimi, minus drobna zmiana obslugi swiatel. Co do VC2013 runtime, sprobuj pobrac I zainstalowac poprawke umieszczona tutaj: https://support.microsoft.com/en-us/help/3179560

Co do samego .exe, to przyszlo mi wlasnie do glowy, ze zapewne sporo osob jezdzi sobie z wlaczona opcja VBO, ktore jest zaimplementowane raczej srednio I moze byc zrodlem dodatkowych bledow wizualnych.  W nowym uaktualnieniu (poza obsluga hamulcow typu K) chwilowo wylaczylem renderowanie VBO. Jesli mozna, to prosze sprawdzic czy zgloszone bledy (migotanie chmur itp) wystepuja nadal w tej wersji.



Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 28 Lutego 2017, 14:13:28
Przywróciłem auto iconify tak jak było i poprawiłem F1.
Ktoś robi dziwne konstrukcje rodzaju false == Console::Pressed( VK_CONTROL ) i przeoczyłem negację.

https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng32-5a8c158d.zip
https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng64-5a8c158d.zip

Nie za bardzo poprawione. Nie da się wyłączać OSD, kolejne naciskanie F1 nic nie daje. Tak samo kolejne naciśnięcie F3 nie powoduje ukrycia rozkładu jazdy. Nie działa ESC dla wyłączenia pauzy w trybie normalnym. W trybie pełnoekranowym nie mogę wyświetlić innego okna na oknie ładowania, na wcześniejszych exe (tych od tmj) mogłem.
Zachowanie z ukrywaniem okienka przy alt-tab jest powodowane przez GLFW, moim zdaniem to właściwie lepiej, ale nic z tym raczej nie zrobię. Ekran ładowania się zmieni poźniej żeby wypisywało na nim komunikaty z konsoli. Na F3 zobaczę później, ale ukrywanie przez ponowne naciśnięcie F1 na pewno działa.

---

@tmj: popatrzyłem na kod od tego kolorowego nieba co zrobiłeś, i niezbyt to ładne. Będziesz jeszcze coś w tym zmieniał, czy mogę przerobić na vbo?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 28 Lutego 2017, 15:04:41
Zachowanie z ukrywaniem okienka przy alt-tab jest powodowane przez GLFW, moim zdaniem to właściwie lepiej, ale nic z tym raczej nie zrobię.
Nie zrozumiałem z tego zdania, co jest lepsze. Dla użytkownika windows zmiana okienek przy alt tab jest podstawową funkcją poruszania się po systemie. Oczywiście to przyzwyczajenie i można to zmienić. Może się wydawać, że jak zabawa z maszyną to nie kombinujemy z innymi aplikacjami. I zgodzę się z tym, jednak całymi dniami testując zachowania exe lub jakiejś nowej scenerii jest upierdliwe. Gdybym miał odpaloną symulację na Twojej kompilacji nie mógł bym napisać teraz tej wiadomości.
PS: Komunikaty u mnie wyłącza F6.
PS2: @tmj, jakkolwiek to wygląda, jest faktem, że dźwięk gwizdka znika na wczorajszej wersji b.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 28 Lutego 2017, 15:13:18
Nie rozumiem. Alt-tab powinien działać. Z tego co zrozumiałem rozchodzi się o to, że nie da się mieć innego okienka zasłaniającego symulator, bo po przełączeniu focusa na inne okienko symulator się chowa, tak?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 28 Lutego 2017, 15:15:08
@tmj: popatrzyłem na kod od tego kolorowego nieba co zrobiłeś, i niezbyt to ładne. Będziesz jeszcze coś w tym zmieniał, czy mogę przerobić na vbo?
Przerob jesli chcesz, ale biorac pod uwage ze polowa danych i tak zmienia sie regularnie i trzeba odswiezac zawartosc bufora, a calosc to raptem ~1500 wierzcholkow, to troche imo sztuka dla sztuki :) Docelowo i tak powinno byc w 90% przesuniete do shadera, zakladajac ze kiedys beda.

PS2: @tmj, jakkolwiek to wygląda, jest faktem, że dźwięk gwizdka znika na wczorajszej wersji b.
A co z dzisiejsza wersja, tez brak, czy gwizdze? Pytam, bo u mnie na 100% gwizdal na 170227b podczas wczorajszych testow.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 28 Lutego 2017, 15:16:11
Tak, po przełączeniu choćby na IE aby zerknąć na forum (oczywiście bez pełnego ekranu), znika symulacja. Wersję 170228 dopiero zassałem, będę sprawdzał gwizdanie. :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 28 Lutego 2017, 15:18:51
Nie rozumiem. Alt-tab powinien działać. Z tego co zrozumiałem rozchodzi się o to, że nie da się mieć innego okienka zasłaniającego symulator, bo po przełączeniu focusa na inne okienko symulator się chowa, tak?
O ile dobrze rozumiem rozchodzi sie o to, ze niektorzy maja otwarte okno symulatora, i jak sie tam malo dzieje to sledza zawartosc jednym okiem, a drugie maja na oknie przegladarki czy gdzie indziej (sam tak robie dosc czesto) Wiec gdy symulator sie chowa, to ta funkcjonalnosc tez zanika.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 28 Lutego 2017, 15:24:39
Przerob jesli chcesz, ale biorac pod uwage ze polowa danych i tak zmienia sie regularnie i trzeba odswiezac zawartosc bufora, a calosc to raptem ~1500 wierzcholkow, to troche imo sztuka dla sztuki :) Docelowo i tak powinno byc w 90% przesuniete do shadera, zakladajac ze kiedys beda.
Zmienia się, ale to nie znaczy że trzeba nachrzaniać 3000 calli do drivera co klatkę. Jedno VBO na wierzchołki, drugie na kolory, połączyć razem w VAO, a bufor z kolorami aktualizować przez glMapBuffer.
Shadera to mógłbym zrobić i teraz, tylko zastanawiam się czy liczenie tych wzorów co klatkę ma sens, bo obecnie jest rzadziej. Można by z taką samą częstotliwością jak teraz renderować do tekstury, ale z drugiej strony wtedy znowu trzeba liczyć dla całego nieba mimo że zwykle widoczny jest tylko fragment, więc pod tym względem liczenie tego co klatkę jest lepsze.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 28 Lutego 2017, 15:29:14
Można by z taką samą częstotliwością jak teraz renderować do tekstury, ale z drugiej strony wtedy znowu trzeba liczyć dla całego nieba mimo że zwykle widoczny jest tylko fragment, więc pod tym względem liczenie tego co klatkę jest lepsze.
Liczyc calosc warto i tak, bo srednia jest wykorzystywana takze do innych celow (kontrola jasnosci obiektow itp), wiec jak zaczniesz kalkulowac tylko to co uzytkownik widzi przez kamere, to beda bezsensowne skoki na podstawie tego, gdzie akurat wcelowana jest kamera.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 28 Lutego 2017, 15:29:48
Tak, po przełączeniu choćby na IE aby zerknąć na forum (oczywiście bez pełnego ekranu), znika symulacja. Wersję 170228 dopiero zassałem, będę sprawdzał gwizdanie. :)
No bez pełnego ekranu to u mnie jest ok, można przełączyć na inne okienko i symulator się nie chowa. Sprawdzone na win7.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 28 Lutego 2017, 16:04:58
Jesli chodzi o dzisiejsze 170228 to melduje, ze gwizdek jest. Wieczorem powalcze z bibliotekami MS na win7.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 28 Lutego 2017, 17:19:29
Na Win10 (i oryginalnym exe) nie ma problemu na pełnym ekranie wyświetlić okienko z konsolą. Symulator nie ma się chować po przejściu do innego okna dlatego, że jak masz 2 monitory to możesz coś zrobić na drugim monitorze. Ja zwykle na drugim monitorze mam Rainsted, rozkład jazdy albo inny dokument.

BTW, alt+tab domyślnie po prostu przykrywa okno symulatora innym oknem, bez chowania symulatora. To jest sensowne zachowanie i tak powinno być. Zauważyłem, że niektóre gry też tak mają. Nie cierpię takich, które uniemożliwiają mi podgląd pełnego ekranu gry podczas używania innych aplikacji, przykładowo przeglądarki.

Ogólnie zachowanie okienek jest nie bez powodu obsługiwane przez system operacyjny i żadna aplikacja nie powinna tego zmieniać. Nie ma sensu ograniczania opcji jakie ma użytkownik. Każdy sobie ustawi po swojemu jak mu pasuje. I jeszcze raz - to było dobrze w starym exe a skoro było dobrze, to nie ma sensu zmieniać takich rzeczy bo to jest krok wstecz. Jest wystarczająco dużo pilnych rzeczy do poprawienia, mam na myśli konkretnych bugów typu niedziałający hamulec pomocniczy w SN61 czy światła oświetlające kabinę i wszystko wokół w kiblach.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 28 Lutego 2017, 17:25:44
światła oświetlające kabinę i wszystko wokół w kiblach.
Masz to nadal na nowszych exe (120227b, 120228)?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 28 Lutego 2017, 17:29:02
Przerzuciłem aktualny stan prac na mojego mastera. I tak wiem, że wszyscy korzystają z repo tmj-a więc będę od czasu aktualizował stan prac u siebie a potem na głównym repo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 28 Lutego 2017, 17:52:46
Sorki, moja wina, przeoczyłem 120227b. Nie, w 120227b jest ok. A tak na marginesie, gdzie jest 120228?
 
światła oświetlające kabinę i wszystko wokół w kiblach.
Masz to nadal na nowszych exe (120227b, 120228)?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 28 Lutego 2017, 17:59:37
@HTD, nie potwierdzam swiecenia kabiny i skladu EN57 juz od exe 170227b. Mam takie dziwne wrazenie jakbys nie czytal zbyt uwaznie informacji o zmianach. Zgadzam sie za to z alt + tab.
@tmj, dzisiejszy plik gwizdze, jezdzi, swieci. Przynajmniej na kilku pojazdach i sceneriach co testuje. Nie ukrywam, ze jestem rozczarowany iloscia osob pobierajacych i testujacych najwazniejszy plik w calej MaSzynie.
Dodam dzis jeszcze pewna wskazowke na wysyp exekow. Przynajmniej z tym komunikatem, ktory publikowalem wczesniej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 28 Lutego 2017, 18:04:56
A tak na marginesie, gdzie jest 120228?
Troche wyzej na tej stronie :)  http://eu07.pl/forum/index.php/topic,28159.msg442600.html#msg442600

uaktualnienia w sumie dosc latwo przegapic, jesli watek posuwa sie szybko, ale jesli mozliwe to wzmianka, ktora wersja byla testowana gdy trafil sie blad, jest przydatna.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 28 Lutego 2017, 18:15:15
Załączam dwa zrzuty ekranu na podstawie których, chcę pokazać wywalenie błędu. W exe pascalowym nigdy nie było problemu, aby zamknąć program za pomocą przycisku x na konsoli. Zaznaczyłem ten przycisk w załączniku. Jednak po przenosinach na C++ próba zamknięcia programu zawsze wywala komunikat o błędzie, na wszelki wypadek ten komunikat załączam powtórnie. Może to nic ważnego, ale większość wysypów, jak nie wszystkie, kończy się u mnie takim komunikatem. Przy testach kiedy symulację zamykam przed jej dokończeniem taka forma zamykania była przeze mnie stosowana. Może to nic nie znaczy, ale uznałem, że warto o tym wspomnieć.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 28 Lutego 2017, 18:21:21
Zgadza sie, tam jest taki glupi blad zwiazany z logowaniem, ktory objawia sie okazjonalnie przy zamknieciu, ale wymagaloby to sporej ilosci drobnych poprawek, wiec na razie to odkladam, bo blad jest malo istotny. Jak mnie dostatecznie zdenerwuje to sie za niego wezme ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 28 Lutego 2017, 19:04:26
Jeszcze dodam, że objawia się na wersji debug a na wersji release nie zauważyłem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 28 Lutego 2017, 19:23:47
Aha, jeszcze taki bug ze światłem jest, że przyciemnienie światła w kabinie prawie nic nie daje. Tzn za mało ściemnia. Oczywiście testowane na wersji 120228.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 28 Lutego 2017, 19:26:56
Wrzuć jakiś poglądowy obrazek, chyba mi ostatnio brakuje wyobraźni.
Zgadza sie, tam jest taki glupi blad zwiazany z logowaniem, ktory objawia sie okazjonalnie przy zamknieciu, ale wymagaloby to sporej ilosci drobnych poprawek, wiec na razie to odkladam, bo blad jest malo istotny. Jak mnie dostatecznie zdenerwuje to sie za niego wezme ;)
Ja mam za każdym razem jak tak zamykam. Tak jak wspomniał Grzegorz w debug mode. Samo zamykanie mnie nie gnębi, liczyłem że jest to przyczyną wysypów w trakcie symulacji.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 28 Lutego 2017, 19:48:52
debug mode to nie jest to samo co wersja debug i release exe.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 28 Lutego 2017, 20:04:26
Szkoda, że nie dopisałeś jaka jest różnica. Mimo wszystko, nie jestem wszystkiego świadomy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 28 Lutego 2017, 20:34:09
O co tu chodzi?

Multiple passed
EVENT ADDED TO QUEUE: sr_toc_sem_ligh2n by et22-216
Traceback (most recent call last):
  File "<string>", line 46, in render
  File "E:\MaSzyna_15_04_uzytkowa\python\lib\site-packages\PIL\Image.py", line 1908, in transpose
    return self._new(self.im.transpose(method))
MemoryError

EVENT LAUNCHED: sr_toc_sem_ligh2n by et22-216
Unknown python texture size!
Traceback (most recent call last):
  File "<string>", line 43, in render
  File "<string>", line 22, in _render
  File "E:\MaSzyna_15_04_uzytkowa\python\lib\site-packages\PIL\Image.py", line 1002, in copy
    im = self.im.copy()
MemoryError

Unknown python texture size!
Traceback (most recent call last):
  File "<string>", line 46, in render
  File "E:\MaSzyna_15_04_uzytkowa\python\lib\site-packages\PIL\Image.py", line 1908, in transpose
    return self._new(self.im.transpose(method))
MemoryError

Unknown python texture size!
Key pressed: [Num+]

Jedyna teksturę jaka używa ekran pytona w tym przypadku ma 128x32x24bpp

CIagle mi na kaliskiej wypieprza exeka nawet numer 28. Niebo dalej migocze chodz przestalo po wyjechaniu za semafor. Tam exeka wywalilo. Niewiem ale stare exe nie było az tak wrażliwe.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 28 Lutego 2017, 20:58:01
"Unknown python texture size" to jest blad, ktory exe wywala gdy nie uda mu sie okreslic wymiarow textury. Albo brakuje mu tej tekstury, albo jest cos nie tak z instalacja pythona. U siebie uzywam 32-bitowej instalacji z https://www.python.org/ftp/python/2.7.13/python-2.7.13.msi umieszczonej w domyslnym folderze I w polaczeniu z Win10 64-bit dziala to bez zadnych klopotow wiec nie, nie jest to kwestia 64-bit windows.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 28 Lutego 2017, 21:01:11
Tak jak pisalem tekstura ma rozmiar 128 32 24bpp i jest wczytywana. Inaczej ekran sie nie wyswietli a sie wyswietla. Na win 7 x32 tez wywalilo. Dzieki. BYlo milo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 28 Lutego 2017, 21:14:19
Sorry,zwyczajnie nie wiem co tam moze byc zle. Wyraznie klopot jest gdzies albo z sama instalacja pythona na twoim komputerze, albo w tym jak jest on polaczony z reszta kodu w .exe (lub kombinacja jednego I drugiego) ale to jest praktycznie w calosci kod wziety z oryginalnego exe, I musialby sie nad tym pochylic autor. Problem nie wystepuje u mnie, wiec nie moge tego zdebugowac.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 28 Lutego 2017, 21:21:59
No dobra ok zamienilem loka z pytonem ma loka bez pytona i wywalilo natychmiast po wcisnieciu f5. Sprawdzalem tego samego loka na td i ladowal sie ok. Ale co innego ladowac td a co innego kaliska. Tak jak pisalem stare exe tak nie szaleja. Teraz test na win 7 x32. Jak wywali to juz koncze z tym.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 28 Lutego 2017, 21:23:13
Sorry,zwyczajnie nie wiem co tam moze byc zle. Wyraznie klopot jest gdzies albo z sama instalacja pythona na twoim komputerze, albo w tym jak jest on polaczony z reszta kodu w .exe (lub kombinacja jednego I drugiego) ale to jest praktycznie w calosci kod wziety z oryginalnego exe, I musialby sie nad tym pochylic autor. Problem nie wystepuje u mnie, wiec nie moge tego zdebugowac.
Wszystko potrzebne do pythona jest dostarczane razem z paczką, więc to raczej nie to.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 28 Lutego 2017, 21:25:39
Stare exe pytona nie wywalaja. Powiem wprost befa cyrki z tym exe. Jak narazie u nielicznych dziala na kaliskiej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 28 Lutego 2017, 21:45:57
EP, u kogo poza toba nie dziala Kaliska? Jesli nie chce im sie tego zglosic tutaj, to raczej bledy same sie nie znajda i nie usuna. Moge sprawdzic i poprawic tylko to, co zobacze u siebie, a u mnie niestety Kaliska jak i reszta scenariuszy na ta chwile dziala. Kilka zgloszonych bledow (slizgajace samochody, hamulec SN61, brak niektorych dzwiekow itp) czeka na poprawienie, bo te widze i jest tu jakis punkt zaczepienia, ale takie klopoty jak ty masz, to ja nawet nie moge wykluczyc czy to zwyczajnie cos nie jest ze sprzetem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 28 Lutego 2017, 22:06:01
To ok ja kompa dla nowego exe nie wymienie. Wlasnie wywalilo na win7 x32 .

Bezprzerwy tym sieje.

Unknown python texture size!
New timetable for en57-1051ra: kaliska/cegielski/17233
Traceback (most recent call last):
  File "<string>", line 47, in render
  File "K:\MaSzyna_15_04_uzytkowa\python\lib\site-packages\PIL\Image.py", line 684, in tobytes
    l, s, d = e.encode(bufsize)
MemoryError
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 28 Lutego 2017, 22:19:36
Widzisz kurcze, nawet crashdump nie daje rady zapisac i produkuje pusty, to raczej nie jest normalne ;/  Ten blad pythona to wyskakuje na wszystkich sceneriach, tych mniejszych tez? Czy tylko na Kaliskiej?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 28 Lutego 2017, 22:43:33
Nie bede tego sprawdzac. Ja juz koncze zabawe z tym exe. Najwyrazniej na moim sprzecie nie bedzie dzialac niezaleznie od systemu. Trudno. Na tym etapie puki stare exe da rade to ok skorzystam.
 Jak juz wszystko przejdzie na to nowe exe to wyglada na to ze bedzie to moj koniec przygody z tym symulatorem. Napewno dla exe nie zainwestuje w nowy komp na to mnie nie stac. Jestem pelen uznania dla ciebie za czas i ogrom pracy jaki w to wkladasz. O takim dynamicznym niebebie i swiatlach marzylem od lat. Niestety jak widac puki co nie kazdy skorzysta.
Pozdrawiam cie serdecznie i zycze wytrwalosci w osiagnieciu zamierzonego celu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 28 Lutego 2017, 22:46:33
Akurat niebo I swiatla sa na tyle prymitywne, ze pewnie calkiem latwo daloby sie je przeszczepic do starego exe, tylko musialby to skompilowac ktos z Borlandem. Ale jakas nadzieja jest ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 28 Lutego 2017, 23:53:21
Witam.
Aż z ciekawości uruchomiłem kaliską z Cegielskim na najnowszym exe i w zasadzie wszystko w normie, jedynie czapajew zjeżdżający po wiadukcie do ZWK nie chciał ruszyć z pod semafora, ale chwilowy restart AI i ożył. Reszta składów mijanych po trasie jechała normalnie. Wczoraj natomiast na poprzedniej kompilacji exe, zbugował się bardzo dziwnie EN57 na L053. Zablokował się nastawnik wirtualnie na najwyższej pozycji jazdy, nie działały hamulce. Zestawy zaczęły rolować, aż wyskoczył komunikat "wheel wear". Ogólnie pociąg widmo. Pomógł dopiero restart jednostki (wyłączenie WS, przetwornicy, sprężarki). Być może to jednostkowy przypadek, nie wina exe.
Pozdrawiam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 28 Lutego 2017, 23:59:57
Ten ET42 ma blednie wpisana predkosc startowa w trainsecie. Zamiast 6 nalezy wpisac 0.1  zreszta nie tylmo ten sklad tak ma.
Bylo o tym w watku o Kaliskiej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 01 Marca 2017, 04:25:54
OK, w dzisiejszym uaktualnieniu mamy pierwsza faze przeszczepu GLFW of Milka. Tzn jak na razie .exe zostalo spiete z GLFW, a do sprawdzenia jest, czy nie rozsypala sie przy okazji obsluga jakis funkcji obslugi klawiatury, zachowania okna itp (na 80-90% posypala sie obsluga eventow wyzwalanych klawiszem, bo tutaj uzywane byly kody specyficzne dla windowsa, ale to sie naprawi. moze) Oprocz tego dobrze byloby, gdyby ktos mogl przetestowac czy wymiana danych przez COPYDATA jeszcze dziala, bo zrobiona jest niejako na doczepke a nie wiem z czym to sprawdzic. Jesli testy pojda dobrze to bedzie mozna przeszczepic reszte, czyli serializacje i wersje 64 bit.

A zeby nie bylo calkiem nudno, to jest tez drobna zmiana w funkcjonowaniu F4. Teraz po nacisnieciu F4 ladujemy na zewnatrz lokomotywy, mniej wiecej w okolicy drzwi do kabiny ktora zajmowalismy, coby nie trzeba bylo za kazdym razem dralowac przez pole do sprzegow. A jesli komus potrzebna jest teleportacja na dalszy dystans, dla obserwacji scenicznych przejazdow czy czego tam, to od tego jest teraz shift + F4.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 01 Marca 2017, 05:45:59
Datownik w aplikacji na 170331?
No coz zawsze to jakies oznaczenie, na koniec marca zrobisz sobie wolne.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 01 Marca 2017, 06:59:44
1. Okno nie pozwala na wyświetlenie innego okna na nim (regresja).
2. Zepsuty anti-aliasing, podczas jazdy widać mocno trzęsące się ostre, niewygładzone linie. Trakcja i wskazówki manometrów wyglądają gorzej.
3. Ignorowanie opcji Napisy z GLUT32.DLL. Czyli brzydki szeryfowy za gruby font.

Na plus:
+ obsługa F4 - IDEAŁ. O to chodziło.
+ oświetlenie (bez świateł, chodzi o słońce i księżyc): IDEAŁ. Odpaliłem misję o tej godzinie co na zegarku, o świcie, i mam w symku to samo co za oknem. Opad szczęki.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 01 Marca 2017, 08:33:30
Włodek, próbowałeś rozpakować nowe exe na czystą paczkę z nagraną tylko kaliską? Jeszcze pozostaje sprawdzenie czy na VBO działa czy nie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 01 Marca 2017, 09:07:23
Witam.
 Panowie, a pod XP Pro SP3 da radę exe 170331 uruchomić w ogóle? Bo u mnie krzyczy o brakujące dl-ki. Jedną znalazłem ( vcruntime140.dll ) w sieci, to teraz żąda api-ms-win-crt-runtime-l1-1-0.dll, i nie mogę namierzyć. Chciałem przetestować współdziałanie z SCS, a tu kicha...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 01 Marca 2017, 09:15:02
1. Okno nie pozwala na wyświetlenie innego okna na nim (regresja).
2. Zepsuty anti-aliasing, podczas jazdy widać mocno trzęsące się ostre, niewygładzone linie. Trakcja i wskazówki manometrów wyglądają gorzej.
3. Ignorowanie opcji Napisy z GLUT32.DLL. Czyli brzydki szeryfowy za gruby font.
ad1: No tu tragedia, robienie więcej niż jednego zrzutu ekranu do pamięci przestało być możliwe, nie można wywlec choćby painta aby zapisać screena. To trzeba naprawić, a jakby się chciało to kiedyś Q zrobił robienie zrzutów pod F12, które zapisywały się do folderu SCR w katalogu głównym z maszyną.
ad2: Dam tego jednego screena z antyaliasingiem na 16 z kabiny siódemki. Wygląda dobrze, na 1 możliwie jak ktoś ma słaby sprzęt. Jazdę sprawdzę wieczorem, teraz nie miałem na to czasu.
ad3: To dla mnie nie jest zauważalne, raczej mało istotny szczegół estetyczny
Na plus:
+ obsługa F4 - IDEAŁ. O to chodziło.
+ oświetlenie (bez świateł, chodzi o słońce i księżyc): IDEAŁ. Odpaliłem misję o tej godzinie co na zegarku, o świcie, i mam w symku to samo co za oknem. Opad szczęki.
Tu nie ma co deliberować, jest super. Tym bardziej super, że dostałem następną swoją zabawkę o którą prosiłem, pod F4 Twierdzono, że za dużo zachodu i niemożliwe, a w ogóle to fanaberia.
Załącznik wielkiej wagi: http://eu07.pl/userfiles/1234/foto-a.PNG (http://eu07.pl/userfiles/1234/foto-a.PNG)
CX Maniak, uruchomiłem pod XP z sp3, ale biblioteki też mi wołał.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 01 Marca 2017, 09:36:17
@tmj: nie wiem jak to zrobiłeś bo znowu zapomniałeś wrzucić na githuba, ale glfw i wm_copydata raczej nie pogodzisz. Wysyłane przez PostMessage można przechywić peekując komunikaty przed glfwpollevents, ale tym nie da się przesyłać payloadu. Trzeba użyć SendMessage a to idzie prosto do callbacka w glfw, więc musiałbyś wydrzeć callbacka z glfw do siebie, przetworzyć niektóre komunikaty i spowrotem przekazać do glfw.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 01 Marca 2017, 11:12:35
Załącznik nr1, wydajność w trakcie symulacji. Zmniejszenie obciążenia procesora, bardzo widoczne zwiększenie ilości FPS. Nie wiem jak to zrobiliście, bo to Kaliska z antyaliasingiem na 16. Dojechałem do Łasku czapajewem z Olechowa, żadnych wysypów i nienormalnych zachowań. Szkoda że do pamięci podręcznej można wrzucić tylko jeden obrazek, bo nie ma jak go zapisać. Stąd tylko jeden. Światła, nie wiem czy na Kaliskiej teren przy torach jest z małych trójkątów, pewnie tak, bo dziś to wygląda jakby był pixelshader.
Załącznik numer dwa, to zapis obciążenia (spadek) po wyłączeniu symulatora. Dla mnie - bomba.
Alt +tab trzeba koniecznie poprawić, jedyne okno gdzie można wyłożyć na wierzch, to alt+ctrl+del. Dlatego jest wydajność systemu na screenie.
Na Kaliskiej w trasie mam 60 FPS, na stacjach około 40.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 01 Marca 2017, 11:27:04
@Krzysiek626:
Mój "słaby sprzęt" to GTX960, opcja anti-aliasing: "Application setting". Może to słabo widać na JPG, na PNG widać wyraźnie. Jest spore pogorszenie i to jest na 100% bug (prawdopodobnie brak prawidłowego zaczytania opcji z ini).

Jak już jesteśmy przy bugach:
 - Przyciemnienie światła w kabinie - wielkość przyciemnienia jest zbyt niska, ledwo widać efekt, opcja z bardzo przydatnej zrobiła się niemal bezużyteczna.
 - Zapalenie jednego światła (np prawego reflektora) daje zbyt słabe oświetlenie, w nocy oznakowanie jest ledwie widoczne, z trudem można w ogóle zauważyć zapalenie światła. Widać na większości scenerii nocnych.
 - Opcja w ini "glutfont yes" nie działa.
 - Odtwarzanie głośnego szumu przy starcie EN57. Uniemożliwia jazdy EN57 (z włączonym dźwiękiem). Uwaga: raz na kilka uruchomień nie ma tego szumu. Testowane na "baltyk_en57". Jak ktoś nie ma, to "baltyk_zima".
 - Gwałtowne gaszenie trójkątów podczas jazdy ze światłami (zapalanie jest już OK, rozjaśniają się płynnie w funkcji odległości, ale gasną gwałtownie). Testowane na "quarkmce2007".
 - Hamulec pomocniczy w SN-61 nie działa. Testowane na "całkowo_sn61"

Nie wiem czy w ramach burzy mózgów mogę coś zaproponować: z tym światłem - zostawić naturalne oświetlenie jak jest, bo jest po prostu idealne. Co do lamp - wprowadzić opcje w ini: headlights=n, gdzie n = 0 - wyłączone, brak, nie działają (do jazdy w dzień), n = 1 - stare lampy, n = 2 - nowe lampy. Opcje będzie można wyrzucić po zmianie oświetlenia na shader.

Co do algorytmu: a gdyby tak zmienić funkcję ładującą trójkąty i dodać do niej dzielenie dużych trójkątów na mniejsze? Taka super prosta "teselacja", to byłoby wręcz banalne. Jak tam gdzieś siedzi funkcja "odczytaj trójkąty=>zwróć trójkąty", zmienić ją na "odczytaj trójkąty=>dla każdego sprawdź czy najdłuższy bok nie większy niż x, jeśli tak, dziel wzdłuż boku tak długo, aż najdłuższy bok nie będzie większy niż x=>zwróć oryginalne i podzielone trójkąty". W ten sposób zniknie problem migania, chociaż może wystąpić spadek FPS. Maksymalną długość podziału można też dać w ini, wtedy dla zera będzie tak jak jest, dla innych wartości to będzie maksymalna długość boku trójkąta w metrach. Warto to sprawdzić. Ten algorytm dla wierzchołków się po prostu nie nadaje. Fajny bajer, ale na dłuższą metę irytujący i psujący klimat. Podatne osoby mogą ponadto padaczki dostać od tego migania ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 01 Marca 2017, 12:00:32
...
Ale kombinujecie, prościej po prostu już zrobić to oświetlenie na shaderze, dzisiaj wieczorem spróbuję.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: pinokio w 01 Marca 2017, 12:55:27
Witam u mnie przy próbie uruchomienia na exe 170331 wyskakuje takie okienko:
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 01 Marca 2017, 13:03:38
Miałem to samo, ale pomogła zmiana pliku glew32.dll na starszy, a nie ten najnowszy
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 01 Marca 2017, 14:17:53
1. Okno nie pozwala na wyświetlenie innego okna na nim (regresja).
Hmm czy to jest w trybie pelnoekranowym, czy w oknie? Jesli w oknie to obawiam sie, ze u mnie to dziala (w zalaczniku)

Cytuj
3. Ignorowanie opcji Napisy z GLUT32.DLL. Czyli brzydki szeryfowy za gruby font.
Font jest akurat bezszeryfowy, bo to Lucida Console :) Dalem grubszy, bo cienkie linie dosc zle sie w moim doswiadczeniu czyta. Moge dac cienszy, ale czy ktos nie bedzie wtedy narzekal ze zle widzi? Pod dyskusje.
Aha, glut jest faktycznie wylaczony, ale to nie ma specjalnego wplywu na font, bo ustawic mozna dosc dowolny. Sprowadza sie do tego, ktore beda dostepne na wiekszosci komputerow, i czytelnosci.

@tmj: nie wiem jak to zrobiłeś bo znowu zapomniałeś wrzucić na githuba, ale glfw i wm_copydata raczej nie pogodzisz. Wysyłane przez PostMessage można przechywić peekując komunikaty przed glfwpollevents, ale tym nie da się przesyłać payloadu. Trzeba użyć SendMessage a to idzie prosto do callbacka w glfw, więc musiałbyś wydrzeć callbacka z glfw do siebie, przetworzyć niektóre komunikaty i spowrotem przekazać do glfw.
No i mniej wiecej tak to dziala. glfw pod windows to ciagle jest okno windows, tyle ze ma wlasna procedure obslugi komunikatow windows. A windows systemowo pozwala na podmiane window proc. Czyli robisz takie cos:
#ifdef _WINDOWS

HWND Hwnd;
WNDPROC BaseWindowProc;

LRESULT APIENTRY WndProc( HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
    switch( uMsg ) // check for windows messages
    {
        case WM_COPYDATA: {
            // obsługa danych przesłanych przez program sterujący
            pDane = (PCOPYDATASTRUCT)lParam;
            if( pDane->dwData == 'EU07' ) // sygnatura danych
                World.OnCommandGet( (DaneRozkaz *)( pDane->lpData ) );
            break;
        }
    }
    // pass all unhandled messages to DefWindowProc
    return CallWindowProc( BaseWindowProc, Hwnd, uMsg, wParam, lParam );
};

(...)

    // setup wrapper for base glfw window proc, to handle copydata messages
    Hwnd = glfwGetWin32Window( window );
    BaseWindowProc = (WNDPROC)::SetWindowLongPtr( Hwnd, GWLP_WNDPROC, (LONG)WndProc );
#endif
i juz. Jak przychodzi COPYDATA to exe obsluguje je pierwsza, a wszystko inne idzie przelotowo do glfw. (COPYDATA tez idzie, tylko moment pozniej)

Na githuba jeszcze nie wrzucilem bo o 5-ej nad ranem juz mi sie nie chcialo. Sprawdze jeszcze u siebie pare rzeczy i pojdzie troche pozniej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 01 Marca 2017, 15:00:35
1. Okno nie pozwala na wyświetlenie innego okna na nim (regresja).
Hmm czy to jest w trybie pelnoekranowym, czy w oknie? Jesli w oknie to obawiam sie, ze u mnie to dziala (w zalaczniku)
Ja wcześniej pisałem, że w trybie pełnoekranowym. Jazda w trybie okienka windows jest dla mnie nieatrakcyjna. Po za tym trudno, aby na wolnej przestrzeni ekranowej czegoś nie otworzyć, dlatego w trybie okienkowym można otwierać inne okna.
Upierdliwe to, bo uruchomiłem symulacje na Kaliskie na innym exe niż chciałem i przez 10 minut nie mogłem nic zrobić, aby się z tego wycofać. Nie mogłem kliknąć na krzyżyk okna konsoli. No chyba że alt+ctrl+del i w oknie kliknąć zamknij aplikację. Chyba nie tak powinno być.
@Krzysiek626:
Mój "słaby sprzęt" to GTX960, opcja anti-aliasing: "Application setting". Może to słabo widać na JPG, na PNG widać wyraźnie. Jest spore pogorszenie i to jest na 100% bug (prawdopodobnie brak prawidłowego zaczytania opcji z ini).
Nie przejmuj się, mam słabszy sprzęt, bo GT9600GT silent i słaby intel E6300, nie miałem kompletnie na myśli Ciebie.
PS: Czcionka ma być czytelna, przed komputerem siedzę w szkłach +3 i astygmatyzm.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 01 Marca 2017, 15:56:53
IMO trzeba by było zrobić przejście pełny ekran/okno za pomocą alt + enter, jak to ma miejsce w większości gier.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 01 Marca 2017, 17:35:25
Działa, wszystko co opisałeś działa!
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: fuji8 w 01 Marca 2017, 19:27:22
Teraz jak włączymy reflektory w jednej i drugiej kabinie, smuga nagle przestaje działać.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 01 Marca 2017, 20:06:46
Anti-aliasing nadal zepsuty. Chudy font też nie ma AA. Światła semaforów z oddali są mocno powiększone, takie wielkie kropy, to ma też związek z AA.
Nie działa prawidłowo filtrowanie tekstur - ruszają się wzorki na torach (widać tylko podczas jazdy), przed zmianą psującą AA było dobrze. Domyślam się, że jak wymuszę AA w sterowniku od karty to będzie OK, ale to tylko ukryje buga. Część osób może mieć nadpisane ustawienia domyślne sterownika karty graficznej i u nich będzie się prawidłowo wyświetlać.
Domyślnie sterownik nie dotyka AA, zostawia to aplikacji.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 01 Marca 2017, 20:15:15
Teraz jak włączymy reflektory w jednej i drugiej kabinie, smuga nagle przestaje działać.
Hmm, czy to bylo w jakims okreslonym rodzaju lokomotywy? Sprawdzajac w EU07 wyglada ze oswietlenie obu stron dziala, w dowolnej kombinacji swiatel.
Warto tez zwrocic uwage, ze przy domyslnej ilosci swiatel w .ini swiatla manewrowe latwo moga 'zniknac' jesli w poblizu jest lokomotywa z wlaczonym calym zestawem. Po prostu exe uzywa dostepnych swiatel na zobrazowanie tego, co ma wiekszy wplyw na cala scenerie. Daj wpis dynamiclights 7 I zobacz, czy to pomoze?

@HTD anti-aliasing sie znalazl i naprawil, bedzie w nastepnym uaktualnieniu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 01 Marca 2017, 20:19:48
Domyślnie sterownik nie dotyka AA, zostawia to aplikacji.
W sterowniku NVidii, można tworzyć profile do każdej aplikacji z zapisem sztywnych reguł. Kilka gier zwykle jest wpisanych już. Ale ja nie o tym, sprawdziłem jazdę z traxem w Drawinowie. U mnie nie ma żadnyh problemów z pythonem, wyświetlacz działa i nic nie wywala. Okazało się jednak, że tekstura nieba
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.
Teraz jak włączymy reflektory w jednej i drugiej kabinie, smuga nagle przestaje działać.
Nie rozumiem jak w jednej i drugiej kabinie? Ale potwierdzam, że zauważyłem na dzisiejszej kompilacji momenty wygaszania smugi (wpis dynamiclights 3).
Exeki testuje na czystej paczce dds z doinstalowaną kaliską na winXP z sp3.
ED:
Cytuj
@HTD anti-aliasing sie znalazl i naprawil, bedzie w nastepnym uaktualnieniu.
To znaczy, że zmieniłem monitor na byle jaki.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 01 Marca 2017, 20:34:06
Okazało się jednak, że tekstura nieba
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
sky skydome_clouds.t3d endsky
I przy wylaczonych w ogole chmurach? (wpisem skyenabled no w .ini)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: fuji8 w 01 Marca 2017, 20:36:48
Pomogła rada @tmj, trzeba było dodać wartość 7 do "dynamiclights".
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 01 Marca 2017, 20:38:38
Zaraz też zrobię 7 we wpisie i sprawdzę niebo.
ED:
skyenabled noU mnie, nie działa. Rainsted podstawia na siłę. Mruga także:
sky sky_dynamic_stratus.t3d endskyNatomiast odpaliłem inny pojazd gdzie nie pytonowego wyświetlacza (ET22) i nie było mrugania. Muszę jeszcze przenieść traxa na inną scenerię, gdzie wiem, że mrugania niema.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 01 Marca 2017, 21:09:52
Czy tylko u mnie nie można włączyć "pauzy"? Ani klawiszem esc, ani pause :/
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 01 Marca 2017, 21:33:02
Pauza nie działa. Przeniosłem niebo sky skydome_clouds.t3d endsky
 i sky sky_dynamic_stratus.t3d endsky
na Bałtyk i mruga.
ED:
OK, znalazłem. Przeniosłem traxa na bałtyk i postawiłem obok siódemki. Odpaliłem na traxie, mruga. Odpaliłem na siódemce nie mruga. Wyszedłem z siódemki F4 i wszedłem do traxa F5, zaczęło mrugać. Po powrocie do siódemki przestało mrugać, tak wkółko. Nie wszystkie modele nieba mrugają, ale jeśli tak to tylko jak się jedzie traxem.
Nie udało mi się wyłączyć nieba wpisem w ini.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 01 Marca 2017, 21:52:19
Wygląda, że python się gryzie z niebem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 01 Marca 2017, 21:56:37
Na 99% renderer w watku pythona wcina sie ze swoimi ustawieniami dla openGL, przestawiajac parametry uzyte do kreslenia nieba. To musi byc jakos synchronizowane, inaczej wystepowaloby nie tylko dla nieba, pytanie tylko jak :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 01 Marca 2017, 22:14:38
Może pythonowi zrobić osobny kontekst? Tekstury chyba da się udostępniać między kontekstami.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 01 Marca 2017, 22:28:07
Witam.
  Panowie walczę z tymi dl-kami, aby odpalić najnowsze exe u siebie pod XP Pro SP3. Trwało to trochę, ale mam wszystkie. Niestety przy starcie wywala błąd "aplikacja nie została właściwie zainicjowana (0xc0000142)kliknij"... itd. Przypuszczam niewłaściwą wersję którejś z bibliotek, tylko która to?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 01 Marca 2017, 22:30:42
Robiłeś restart kompa? Zablokuj jeszcze zapis pliku $.scn U mnie pomogło na wysyp symulacji z "niewiadomych" przyczyn na Quarku.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 01 Marca 2017, 22:47:22
Restartu nie robiłem. Te Dll-ki pościągałem po prostu z neta i powrzucałem do folderu z Maszyną. Tyle tylko że są różna wersje 6.3.9600.16384 albo 10.0.10586.212. Są też jeszcze inne. No i która właściwa jest?  To że mają być pod 32bit to wiadomo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 01 Marca 2017, 22:55:44
Tych z MS dll nie wrzuca się od tak do folderu z maszyną. Wysłałem Tobie PW.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 02 Marca 2017, 04:21:59
Zaraz mnie cos trafi :x

Przy testach wyszlo, ze przy aktywnym pytonie nie migaja chmury, ale niebo za nimi. Pomyslalem ze moze msci sie tutaj reczne renderowanie, bo to jednak chwile trwa wiec pyton mial wieksza szanse wciac sie w srodek ze swoim przebudowywaniem tekstury. Przerobilem niebo na VBO, zeby rysowalo sie za jednym zamachem, ale nie, mrugalo dalej. Zaczalem przepisywac pytona, zeby uzywal wlasnego kontekstu, ale wylazlo ze kazdy lok z pytonem ma swoj wlasny watek, a to by znaczylo osobny kontekst i osobne dodatkowe niewidzialne okno (bo glfw inaczej kontekstow nie robi) dla kazdej lokomotywy :|
Z ciekawosci przesunalem rysowanie nieba na pozniej, tzn po rysowaniu terenu, i przestalo migac D: ale to akurat nie rozwiazanie, bo gryzlo by sie z elementami przezroczystymi itp...

nie przedluzajac jeszcze bardziej, poprawka sprowadzila sie do recznego ustawienia 'nie uzywaj tekstury' na czas renderowania nieba.
GfxRenderer.Bind( 0 );
ot i caly fix. z jakiegos powodu przebudowanie tekstury przez pytona w trakcie psulo rysowanie geometrii, mimo ze ona tej tekstury (ani zadnej innej) do niczego nie uzywala.

Tyle z tego dobrego, ze teraz mamy niebo rysowane przez VBO zamiast recznie. Chociaz tego akurat, w odroznieniu od migotania, specjalnie nie widac :d  A takze poprawiona obsluga anti-aliasingu, jak wczesniej wspomnialem.

edit: aha, i pauza pod Esc jest naprawiona.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 02 Marca 2017, 05:50:27
Nurtuje mnie czemu nie kazde niebo mrugalo. Pauza byla pod klawiszem [pause], pod [escape] bylo przyspieszanie symulacji w debug mode (wyglada jak szybkie przewijanie obrazu do przodu). Jednak nie wiem czy ktos to uzywal, ja nie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 02 Marca 2017, 06:47:19
No prawie dobrze ;) Teraz żeby tylko z powrotem eventy od klawiszy działały. Sprawdzałem na Zwierzyńcu - próba hamulca z obsługą klawiatury numerycznej nie działa.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 02 Marca 2017, 08:39:39
Poprawka udana. Niebo w Drawinowie nie mruga, antyaliasing na 16 daje popalić przy wyszukanej jakości obrazu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 02 Marca 2017, 14:10:50
Nurtuje mnie czemu nie kazde niebo mrugalo.
Migotalo tylko to niebo ktore jest niejako "za" chmurami, wiec w sceneriach w ktorych uzyte jest statyczne niebo bez alfy migotanie (razem z calym niebem) bylo maskowane. Efekt wylazil w scenach gdzie uzyte byly polprzezroczyste chmury, pokazujace to co jest za nimi.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 02 Marca 2017, 16:46:48
Zaczalem przepisywac pytona, zeby uzywal wlasnego kontekstu, ale wylazlo ze kazdy lok z pytonem ma swoj wlasny watek, a to by znaczylo osobny kontekst i osobne dodatkowe niewidzialne okno (bo glfw inaczej kontekstow nie robi) dla kazdej lokomotywy :|
Co masz na myśli? Przecież python jest liczony tylko dla aktywnej kabiny.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 02 Marca 2017, 16:48:00
Ponieważ exe samo w sobie jest nieźle dopieszczone, postanowiłem sprawdzić jak przeciętny użytkownik poradzi sobie z instalacją paczki opartej na ostatniej kompilacji. Z mojego rozeznania wynika, że każdy z nas co miał w tym wątku problemy z odpaleniem aplikacji, radził sobie na swój sposób. Czyli inaczej. Podjąłem próbę sprawdzenia trudności jakie pojawiły się po przejściu na C++, być może jest to przyczyna małej ilości osób zabierających głos w tym wątku. Szczególnie dziwny wydał mi się brak głosu developerów, beta testerów.
Oto lista rzeczy które zrobiłem:
1. Na sformatowany dysk zainstalowałem winXP 32 bit z sp3.
2. Zainstalowałem sterowniki do płyty głównej, dźwięk, sie i pozostałe do czipsetów.
3. Zainstalowałem sterowniki do karty graficznej GF 9600GT z chłodzeniem pasywnym.
4. Zainstalowałem biblioteki MS 2013 i 2015 z podanych na w wątku linków.
5. Przeniosłem na dysk C (partycja systemowa), katalog główny symulatora. Jest to paczka, która działa na innym dysku z systemem winXP.
6. Odpaliłem rainsted, zaznaczyłem TD, wybrałem dzisiejsze exe i dostałem komunikat jak w załączniku 1.
---------
To niestety nie jest instrukcja uruchomienia, bo nie zadziałała. Moim skromnym zdaniem, należy przemyśleć sposób instalacji tak, aby była łatwiejsza dla przeciętnych zjadaczy chleba. Taki poradnik moim zdaniem jest potrzebny, trzeba go opracować i przypiąć w tym dziale.
Nie szukałem dalej rozwiązania problemu, ponieważ uważam, że już instalacja bibliotek MS jest zbyt skomplikowana, aby jeszcze szukać dalszych ekwilibrystycznych rozwiązań.
Dla mnie to teraz najpilniejszy problem.
Załącznik 2: widok instalacji systemowych.
Załącznik 3: widok katalogu głównego z maszyną.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: joey w 02 Marca 2017, 18:04:33
Odpalane na na Linuksie (Mint 17.1) + Wine 2.2, exe eu07++170302, proba nacisniecia strzalki w kabinie konczy sie efektem jak w filmie (kolor rozjasniony przez Youtube, bo lepiej widac), trzesienie kamery zatrzymuje dopiero F4.

Na TD, gdzie z natury FPS jest wyzszy, drgania sa znacznie, znacznie mniejsze, wystepuja w wiekszosci przypadkow tylko zaraz po wcisnieciu i puszczeniu strzalki i ustaja po ok. sekundzie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 02 Marca 2017, 18:19:16
Nie związane z wine, u mnie działa ok.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 02 Marca 2017, 18:29:58
To wygląda jakby przeskakiwał miedzy pozycjami lusterek prawym i lewym.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 02 Marca 2017, 18:44:33
Moim skromnym zdaniem, należy przemyśleć sposób instalacji tak, aby była łatwiejsza dla przeciętnych zjadaczy chleba. Taki poradnik moim zdaniem jest potrzebny, trzeba go opracować i przypiąć w tym dziale.
Nie szukałem dalej rozwiązania problemu, ponieważ uważam, że już instalacja bibliotek MS jest zbyt skomplikowana, aby jeszcze szukać dalszych ekwilibrystycznych rozwiązań.

W jakims stopniu moze pomoc wlaczenie czesci bibliotek do .exe, ale nie wiem na ile. Na probe skompilowalem symulator razem z CRT, i wrzucilem do paczki biblioteki, ktorych potrzebuje do uruchomienia, i z ktorymi u mnie chodzi. Wrzuc to do tego testowego katalogu, nadpisz wszystkie istniejace pliki tymi z zalacznika, i zobacz czy sie polepszy?

fake edit: i doopa, bo limit zalacznikow jest 1500kb, a archiwum ma 1520 ;/  rozdzielilem na dwie paczki
To wrzucaj na nasz upload, przedrostek bugs-, tam limit jest znacznie większy: http://eu07.pl/upload/ | @macius5991

Odpalane na na Linuksie (Mint 17.1) + Wine 2.2, exe eu07++170302, proba nacisniecia strzalki w kabinie konczy sie efektem jak w filmie (kolor rozjasniony przez Youtube, bo lepiej widac), trzesienie kamery zatrzymuje dopiero F4.
Niestety, u mnie chodzenie dziala normalnie :<  jest mozliwosc, ze wywolane jest to zmianami w obsludze poruszania sie w kabinie i wystepuje przy niskim fps, ktory nie bardzo mam jak przetestowac. Mozesz sprawdzic wartosc FPS wyswietlana pod F8?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 02 Marca 2017, 19:02:03
Nic z tego, ten sam blad. Jedyna zmiana to najpierw pokazalo sie okno o nieznanym dostawcy aplikacji z pytaniem uruchom lub nie. Odpale "starego" windowsaXp, wejde z niego w ten katalog i zrobie probe odpalenia exe.
ED:
Ze starego systemu XP ten sam katalog z dzisiejszym exe i exe+biblioteki, odpalone. W załącznikach wyniki badań. Wygląda na to, że problem tkwi w konfiguracji systemu. Stary XP postawiłem 22 marca 2015, odpala się długo, zaliczył kilka napraw. W komputerze mam teraz 2 razy XP na oddzielnych dyskach i płytę w której mogę pod F12 dedykować dysk z którego startuje OS.
ED2:
W załączniku 3, zestaw uzbieranych bibliotek i pomocy od MS na "starym" XP.Oba systemy instalowane z tej samej płyty CD i na tej samej płycie głównej komputera.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: joey w 02 Marca 2017, 20:24:52
Mozesz sprawdzic wartosc FPS wyswietlana pod F8?
Od 14.8 do 20 FPS.
To wygląda jakby przeskakiwał miedzy pozycjami lusterek prawym i lewym.
Wcisniecie ctrl+strzalka powoduje ustanie trzesienia kamera i poprawne przelaczenie do widoku lusterka, do momentu puszczenia klawiszy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 02 Marca 2017, 20:38:23
Od 14.8 do 20 FPS.
Aha, to by wyjasnialo zachowanie. Dalem poprawke, w nastepnym uaktualnieniu powinno byc uporzadkowane.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 02 Marca 2017, 20:52:56
Brak uruchomienia na czystym XP wiąże się zapewne z innym DirectX (a konkretnie DirectSound) niż na długo używanym systemie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 02 Marca 2017, 21:20:28
To ma sens, nie pamietam czy XP nie wymaga w ogole instalacji directX, bo chyba 'w pudelku' nie ma, a juz na pewno nie aktualna.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 02 Marca 2017, 21:37:40
To może jakiś check i okienko z czytelnym błędem? Można dodać do wymagań, ale tego i tak nikt nie czyta...
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 02 Marca 2017, 21:40:21
Nie wiem czy sie da, bo tego typu blad wystepuje niejako jeszcze przed uruchomieniem .exe. Chociaz ten akurat troche dziwny jest, bo brak .dll z reguly wiaze sie z komunikatem o braku danej .dll, a nie takim krzakiem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 02 Marca 2017, 21:42:08
Wątpię że o to chodzi, directsound był w ...directx 8, na pewno dostarczany z XP.
PS: dependency walker pokazuje że python27.dll wymaga msvcr90.dll (vs2008). może o to chodzi?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 02 Marca 2017, 21:50:46
Jeśli .dll jest w innej wersji to występuje ten sam błąd co pokazał Krzysiu, miałem to samo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 02 Marca 2017, 22:08:52
Z porownan dat plikow wychodzi, ze mam na starym windowsie pliki z data 20160208, mimo ze jest to directx 9.0C. Na stronie MS znalazlem DX9.29,ale jego instalacja nic nie zmienila. Pozostaje skopiowac folder dllek i wkleic brakujace do nowego. System postawilem jako doswiadczalny,  nie bedzie straty.
9.0c instalowany jest z plyty xp.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 02 Marca 2017, 22:52:36
a ten redistibutable c++ 2008 sprawdzałeś?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 02 Marca 2017, 23:10:05
Bingo.
Przekopiowałem część bibliotek, ale nic to nie dało. Grzebać w tym jest trudno. Doinstalowałem redistibutable c++ 2008 i ruszyło. Teraz taka prośba o założenie wątku i przyklejenie go w dziale na warsztacie. Wątek należy zamknąć w jednym poście i publikować tam ewentualne pliki potrzebnych bibliotek, ogólnie należy zebrać co potrzeba w jednym poście, tu zrobiło się zbyt zawile. Propozycję kieruję do @tmj i @Milek7 jako, że najwięcej mogą dopomóc, a także dysponują największą wiedzą.
Mam sygnały, od przeciętnych zjadaczy chleba, że jest taka potrzeba.
PS:
Na czystym systemie podskoczył FPS
ED:
Dodałem załącznik z zawartością dodaj usuń programy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 02 Marca 2017, 23:26:50
Tak z ciekawosci, sprawdz jeszcze moze, czy uruchomi sie na tym 'czystym' systemie po odinstalowaniu Redistributable dla 2013 i 2015? 2013 jest teraz teoretycznie wlaczony do .exe, a 2015 jest dla wersji kompilowanych przez Firleju i Milka, wiec jesli bawimy sie w skonstruowanie najprostszej wersji instalacji, byc moze da sie ja odseparowac.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: 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.
Cytuj
PS: dependency walker pokazuje że python27.dll wymaga msvcr90.dll (vs2008). może o to chodzi?
Nie widziałem tego dopisku, byłoby szybciej, dobrze że powtórzyłeś post.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 02 Marca 2017, 23:51:04
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
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 02 Marca 2017, 23:57:17
No, racja taka, że zapomniałem Firleja wymienić. :(
Co do paczki 170303, mam na 3 dysku win7, co też nie chciało ruszyć. Tam wypróbuję ją jutro w całości. Dziś jeszcze tu na nowym xp i koniec. Także chwila jeszcze.
ED:
Pakiet działa, trzeba jeszcze taką paczkę na 64 bitowe systemy naszykować (bardzo proszę) i będzie dobrze. Nawiasem mówiąc instalki vc2008 i 2013 widać jako exeki w rainsted i można je odpalić przez rainsted.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 03 Marca 2017, 00:13:34
Wersje 64bit bedzie musial Milek zrobic, bo tylko on ma na razie dzialajaca kompilacje :)  Tam bedzie chyba trzeba dorzucic vc2015 i 64-bit wersje .dll dla pythona, i glfw.dll bedzie nowsza.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 03 Marca 2017, 00:16:03
Jutro zrobię moje buildy. Do nich trzeba jeszcze dorzucić cały folder z pythonowymi bibliotekami.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 03 Marca 2017, 00:18:35
To ja jeszcze dopytam, jest coś jeszcze dopisane/poprawione między 170302b i 170303? Oprócz tego że odchudzone o biblioteki jest.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 03 Marca 2017, 00:26:24
Jest tam mala poprawka ktora powinna teoretycznie uleczyc zgloszone miotanie sie po kabinie przy niskim FPS, poza tym roznicy o ile dobrze pamietam nie ma.

Aha, od 170302 w gore jest dodatkowa opcja w .ini
vsync yes
uzycie vsync no usuwa limit 60 (zazwyczaj fps) i symulator liczy tyle, na ile mu sprzet pozwala. Dodana glownie dlatego, ze po przejsciu na glfw i wlaczonej synchronizacji zdarzaly mi sie brzydkie spadki framerate do ~30 fps, mimo ze aktualna predkosc rysowania byla ok. 50-55. Domyslnie opcja ustawiona jest na yes, wiec dla zwyklego uzytkownika w zasadzie tak, jakby nie istniala, ale jako opcja jest.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 03 Marca 2017, 00:33:05
Mamy jeszcze jakieś pomysły na teraz? I tak już jest dziś.Dziękuję za dobrą współpracę.

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: joey w 03 Marca 2017, 00:35:45
Jest tam mala poprawka ktora powinna teoretycznie uleczyc zgloszone miotanie sie po kabinie przy niskim FPS
Uleczyla, dziala pieknie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 03 Marca 2017, 00:39:49
@Milek7, zapomniał bym, jak tam wczorajsze prace nad szaderami, wspominałeś że wieczorem coś zrobisz.
PS, ktoś poleci cichą klawiaturę, bo chcą mnie tu zamordować? @tmj, coś na rano wydłubiesz jeszcze? Zaplanować dzień chciałem.
Wyczaiłem bład na kaliskiej, Ostanie linijki logu:
Loading texture data from "dynamic\road\a4\tabr.dds"
------------------------------------------------------
init default physic values for golfj, [golf], []
LOAD FIZ FROM dynamic\road\golf\golf.fiz
CERROR: 0, SUCCES: true
check locomotive parameters...
Braked
Loading - binary model: dynamic\road\golf\golf.e3d
Dalej nie chce ruszyć na ostatnim.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 03 Marca 2017, 01:15:54
@tmj, coś na rano wydłubiesz jeszcze? Zaplanować dzień chciałem.
Ale w jakim sensie :)  jesli chodzi o jakies uaktualnienia to najprawdopodobniej przez dzien-dwa nie, bede probowal podczepic pozostale zmiany Milka i uruchomic wesje 64 bit.

Kaliska obawiam sie laduje sie u mnie normalnie na najnowszej wersji, nie wykazuje bledow ani nic :/
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 03 Marca 2017, 06:43:44
Co do chodzenia po kabinie, to coś jest nie tak. Odpalam sobie TD gdzie mam teoretycznie 100FPS. Podczas chodzenia po kabinie ekran trzęsie się, efekt jest tragiczny. Na TD to ja miałem ponad 60FPS-ów nawet na karcie wbudowanej w laptopa, i to tej gorszej z dwóch. Problemem nie jest wydajność symulatora czy silnika graficznego, tylko okropna prowizorka w obsłudze poruszania się po kabinie. Proponuję następujący oczywisty algorytm:

Klawisze strzałek powodują nadanie kamerze przyśpieszenia, które następnie jest szybko wytracane (hamowane) po zwolnieniu klawisza. Czyli klawisze sterują przyśpieszeniem, w najbardziej uproszczonym przypadku prędkością, a nie bezpośrednio pozycją kamery. Pozycja kamery musi być obliczana dla każdej klatki wyświetlania na podstawie czasu symulacji, niczego innego, dzięki temu szybkość poruszania NIE ZALEŻY od FPS.

Uproszczony zapis:
 - jeśli wciśnięto klawisz, nadaj wartość przyśpieszenia a = a1, zwiększaj dla każdego kroku symulacji (klatki) prędkość poruszania się w danym kierunku
   jako v = a * t gdzie t jest czasem symulacji niezależnym od FPS. v nie może przekroczyć oczywiście vmax.
- jeśli wciśnięto inny klawisz, ale nie zwolniono poprzedniego - nadaj wartość a = a1 dla składowej ruchu w kolejnym kierunku.
- jeśli zwolniono klawisz, nadaj wartość przyśpieszenia ujemną, czyli zmniejszaj prędkość poruszania się v = a * t, dla a = -1 aż [v = 0], czyli aż ruch w kierunku wektora przyśpieszenia nie ustanie.

Oczywiście to przesadne uproszczenie, gdyż należy wziąć pod uwagę kierunek wektora prędkości i wektora przyśpieszenia, dodawania i mnożenia wykonywać dla odpowiednich wektorów. Ruch powinien także zostać zatrzymany (poprzez wyzerowanie prędkości i przyśpieszenia) w momencie przekroczenia limitu kabiny w kroku obliczeń, musi to nastąpić przed zastosowaniem przemieszczenia kamery dla danej kratki. Czyli jeśli x = vx * t < x0 to vx = 0, ax = 0, x = x0.

To co prawda nie jest jeszcze "jak w Doomie" - ale już 100x lepiej. Koniec szarpania kamerą. Płynna animacja.

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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 03 Marca 2017, 07:08:39
No ja myślę, że nie jestem najbardziej odpowiednią osobą do zakładania nowego wątku. Już mnie tutaj obiegli. Co najwyżej można zamknąć temat konwersji i nową nazwę dać adekwatną do planowanych zmian w exe. Ja obecnie tylko zbieram zmiany i przerzucam pomiędzy repozytoriami.

@HTD: poruszanie się po kabinach jest właśnie teraz obliczane po czasie symulacji i stąd są te błędy (co jest bardzo ciekawe swoją drogą). Może bardziej chodzi o to, że nie obcina przesunięcia do granicy i przeskakuje do tej po drugiej stronie?

No i mimo wszystko mamy ciągle błędy u EP08 które nie zostały rozwiązane a warto by było jednak stwierdzić co się dzieje, nawet jeśli to jest jakiś błąd instalacji.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 03 Marca 2017, 11:14:46
Oto mniej więcej jak wyobrażam sobie ruch po kabinie:
https://www.codedog.pl/x/movement.html (https://www.codedog.pl/x/movement.html)

Wszystko jest w komentarzach do skryptu, można to skopiować na dysk i pobawić się parametrami.
Chodzenie działa na klawisze strzałek, sam skrypt odpala się w większości przeglądarek chromo-podobnych.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 03 Marca 2017, 11:45:24
To bardziej nadaje sie do watku: Planowane zmiany do exe. @Stele chcial jak najszybciej uzyskac stabilne exe, aby jeszce w tym roku poskladac paczke calosciowa. Prosil, aby dopiescic to co jest, naprawic znane w tej chwili problemy. Istotniejsze jest poprawienie przeliczania oswietlenia na pixele, niz zmiana sposobu poruszania sie po kabinie. Zmiana funkcji klawiszy i ppm a takze lpm i scrola, bedzie bledem. W tym roku paczka calosciowa nie moze zawierac takich zmian. Exe zostalo dopiero przepisane na c++ i po osiagnieciu stabilnosci trafic do paczki. Wymyslanie zmian, to odwlekanie wydania pc2017.
We wspomnianym watku, rodzi sie nowe zycie symulatora i dzis nawet nie wiemy jak bedzie wygladal.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 03 Marca 2017, 11:51:14
Musimy ustalić jakieś wytyczne co do stylu kodu, bo tak to będziemy się poprawiać w kółko.
Jeżeli o mnie chodzi, to preferuję:
- wcięcia tabami (przy przenoszeniu do drugiej lini taby do poziomu wcięć, później spacje do ewentualnego wyrównania argmentów)
- spacje przed otwierającym ( słowach kluczowych
- brak spacji za ( i przed )
- { w osobnych liniach
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 03 Marca 2017, 12:15:53
To bardziej nadaje sie do watku: Planowane zmiany do exe. @Stele chcial jak najszybciej uzyskac stabilne exe, aby jeszce w tym roku poskladac paczke calosciowa. Prosil, aby dopiescic to co jest, naprawic znane w tej chwili problemy. Istotniejsze jest poprawienie przeliczania oswietlenia na pixele, niz zmiana sposobu poruszania sie po kabinie. Zmiana funkcji klawiszy i ppm a takze lpm i scrola, bedzie bledem. W tym roku paczka calosciowa nie moze zawierac takich zmian. Exe zostalo dopiero przepisane na c++ i po osiagnieciu stabilnosci trafic do paczki. Wymyslanie zmian, to odwlekanie wydania pc2017.
We wspomnianym watku, rodzi sie nowe zycie symulatora i dzis nawet nie wiemy jak bedzie wygladal.
Ogarnięcie kamery jest 100x prostsze od pixel shadera. Latać też nie może. Kontrolę fov na rolce bym chciał, by ustawić porządnie kamery w ciasnych kabinach.
TMJ, Milek, ogarniacie zgłoszone bugi i wzajemnie swoją wizję? Bo ja nie. :D Jeden wątek do wszystkiego jest kłopotliwy. Jak nie chcecie tego smfowego bugtrackera, to może jakiś własny sobie zróbcie jak Ra? Albo poddział na forum i każdy problem/ficzer do rozwoju w osobnym wątku?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 03 Marca 2017, 12:16:26
W katalogu głównym masz cały styl opisany w pliku .clang_format. Użyj formatera to Ci wszystko ustali (do VS jest dostępny jako plugin).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 03 Marca 2017, 12:28:38
Ogarnięcie kamery jest 100x prostsze od pixel shadera. Latać też nie może. Kontrolę fov na rolce bym chciał, by ustawić porządnie kamery w ciasnych kabinach.
Ja też chciałem zoom, jak zapewne pamiętasz. Stosowne pliki miałem już na 1 stycznia, ale nie wyszło, nie mam pretensji, te pliki posiadało wiele osób. Ja pisałem, że fov to na [shift]+[lpm] i [shift]+[ppm], jeśli ze scrolem to pod kontrolą [shift] lub [alt]. W danej kabinie ustawiamy raz kąt widzenia i rolka nie może przypadkowo to zmienić. Latanie zdaje się poprawiono z tego co pisał zgłaszający.
PS:
Na nowym XP, odpaliłem Kaliską i dojechałem do celu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 03 Marca 2017, 12:47:13
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".
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 03 Marca 2017, 12:47:53
@tmj, jesteś w stanie doinstalować do VS2013 build tools 2015? To rozwiązałoby problemy z wymaganiami odnośnie bibliotek w systemie pomiędzy poszczególnymi buildami.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 03 Marca 2017, 12:57:40
Tylko różne pojazdy wymagają różnych fov do komfortowej jazdy. Nie wyobrażam sobie umieszczenia tego w mmd by skakał perspektywą przy zmianie widoku na zewnętrzny.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 03 Marca 2017, 13:17:32
@tmj, jesteś w stanie doinstalować do VS2013 build tools 2015? To rozwiązałoby problemy z wymaganiami odnośnie bibliotek w systemie pomiędzy poszczególnymi buildami.
Zobacze, chociaz nie obiecuje bo ruszanie instalacji takiego kombajnu to zawsze proszenie sie o klopoty :d
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 03 Marca 2017, 13:38:42
zmergowałem z tmj
https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng32-6545ab39.zip
https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng64-6545ab39.zip
oprócz bibliotek dołączonych w zipie do uruchomienia potrzebny jest runtime vs2015.
dla wersji 64bitowej należy przygotować sobie katalog python64: zainstalować paczkę pythona, zainstalować w niej pillow, i skopiować katalogi DLLs i Lib do katalogu python64 w symulatorze. katalog local należy przekopiować z obecnego folderu python.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 03 Marca 2017, 14:25:32
Cytuj
....dla wersji 64bitowej należy przygotować sobie katalog python64: zainstalować paczkę pythona, zainstalować w niej pillow, i skopiować katalogi DLLs i Lib do katalogu python64 w symulatorze. katalog local należy przekopiować z obecnego folderu python.....
Napisz to zrozumiale dla przeciętnego Kowalskiego co nie wie co to pillow i skąd wziącz paczkę pythona. Ja z tego rozumiem ostatnie zdanie tylko.

PS:
 miało być wyrzucone jak było puste.:)
ED:
 Zrobiłem to samo co wczoraj, ale tym razem postawiłem WIN7, doinstalowałem MS 2008, 2013 i 2015. Nie poszło na żadnym exe c++
załącznik ze stanu systemu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 03 Marca 2017, 14:38:16
instalator pythona: https://www.python.org/ftp/python/2.7.13/python-2.7.13.amd64.msi
ściągasz, instalujesz.
wciskasz win+r, wpisujesz cmd, enter. Przechodzisz do katalogu z zainstalowanym pythonem\Lib\site-packages, np. jeżeli python zainstalowany w C:\Python27_64\ to wpisujesz cd C:\Python27_64\Lib\site-packages, następnie ..\..\python.exe pip install pillow. Jak się skończy to zamykasz okienko. W katalogu z maszyną tworzysz katalog python64, i kopiujesz do niego katalogi Lib oraz DLLs z katalogu instalacji pythona. Z katalogu python w maszynie kopiujesz folder local do katalogu python64.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 03 Marca 2017, 15:03:56
@Milek7, po wykonaniu tych czynności, exe odpaliło na TD.scn, załącznik.
Dziękuję za wskazówki, proszę pamiętać, że większość z nas, nie jest obyta z lakonicznymi instrukcjami. Czy instalacja katalogu z pythonem na dysku C może być usunięta?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 03 Marca 2017, 15:09:07
tak, możesz odinstalować paczkę pythona.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 03 Marca 2017, 15:15:48
Dzięki. Jeszcze jedna rzecz mnie nurtuje, paczka instalacyjna powinna być jedna dla systemów x86 i x64. Zalety są oczywiste, takiej konfiguracji. Natomiast teraz widzę jakby rozdzielność systemu zawartości bibliotek w samym exe, jak także rozdzielność bibliotek montowanych w katalog eu07. Jak planujecie rozwiązać to zagadnienie?
Pytanie jest także do @tmj i @firlejczyka.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 03 Marca 2017, 15:29:47
Można dać obie wersje i przełączanie skryptem. Kwestia niepotrzebnego zwiększenia wagi paczki. Pythony trochę ważą
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 03 Marca 2017, 15:33:44
python to pewnie tak jak jest teraz, czyli dwa katalogi dla x32 i x64.
Co do innych dll to najlepiej by było jakby exe i dll dla niego wrzucić do osobnych katalogów. Problem jest taki, że rainsted nie potrafi uruchamiać exe z katalogów. Zgłosiłem już to kilka dni temu na bugtrackerze rainsteda.
Jeżeli nie to można pokombinować i zlinkować tak żeby oczekiwało .dll z inną nazwą dla wersji x64, tak żeby dało się wrzucić je wszystkie do głównego katalogu bez konfliktów.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 03 Marca 2017, 15:43:26
Katalogi z pythonem to jakieś 80mb obydwa. Powinny być z dystrybucją paczy lub paczek całościowych. Nie znam się na tym więc może wywołam uśmiech, ścieżka do dllek to taka jak jest do katalogu głównego, czy można by je rozdzielić (dwa katalogi), jak w przypadku pythona. Exe uwolnić od bibliotek, zostawił bym jako uniwersalne. Jeśli nie tak, to nauczyć Rainsteda odróżniać x86 od x64, niech uruchamia właściwą strukturę.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 03 Marca 2017, 15:50:51
windows szuka dll w katalogu z exe, więc nie da się rozdzielić bez wrzucania exe do innego katalogu.
ewentualnie faktycznie można zlinkować wszystko statycznie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 03 Marca 2017, 16:41:31
OK, teraz zabieramy się za problem, uruchomiłem kaliską, dwa razy, uruchomiłem td, kilka razy. Jednak nie pojeździłem. Wszystkie lokomotywy na scenerii stają. Mają tryb pod F2 Emergency_brake. Załącznik ze stanem loka, nie można ich ruszyć. WIN7 64bit i paczka od Milka7. Załącznika nie ma bo ze schowka, po wklejeniu do painta jest czarny obraz.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 03 Marca 2017, 17:11:20
heh, ctrl włączał radiostop :)
https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng32-b95af30f.zip
https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng64-b95af30f.zip

ale mnie nudzi to buildowanie dla dwóch platform, pakowanie exeków, kopiowanie z vm, wysyłanie na serwer.. chyba sobie podłączę jakieś CI na githubie
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 03 Marca 2017, 17:32:57
Milek, dałbyś z dwie godzinki czasu. To ja się produkuje, screeny robię, loga pakuje żeby potwierdzić błąd który Krzysiek zgłosił. A tu pyk i poprawiona wersja już na forum :-)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 03 Marca 2017, 17:52:53
U mnie nadal emergency_brake. Może alt+tab coś mąci, używam tego intensywnie. Albo pisanie na klawiaturze z symulatorem w tle.
Po za tym, ja napisałem o problemie po 16 godzinie, a Ty załączyłeś do poprawki exe z 15:37, jasnowidz? ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 03 Marca 2017, 18:01:42
ups, przepraszam za zamieszanie
skopiowałem exe z folder release, a zbudowałem debug ;p
https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng64-b95af30f-2.zip
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 03 Marca 2017, 18:03:51
Między czasie, wywala się bałtyk ep08. Log w załączniku, brak crasha. Wywala się na pierwszych eventach.
mam coś: załącznik.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 03 Marca 2017, 18:08:29
ok, potwierdzam.
z ciekawości, tylko u mnie czy u tmj też?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 03 Marca 2017, 18:13:04
Nie, u mnie chodzi ok. Blad jest pewnie tutaj:
Loading Python ...
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: No module named PIL

Symulator ma jakies dodatkowe pakiety pythona o ile sie nie myle, i na golej instalacji albo ich brakuje, albo gryza sie z wersja 64bit?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 03 Marca 2017, 18:14:09
Na wersji 32 bit od tmj odpalał się bałtyk.  Ale siedzę na 64 bitowym teraz>
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 03 Marca 2017, 18:20:30
Nie, u mnie chodzi ok. Blad jest pewnie tutaj:
Loading Python ...
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: No module named PIL

Symulator ma jakies dodatkowe pakiety pythona o ile sie nie myle, i na golej instalacji albo ich brakuje, albo gryza sie z wersja 64bit?
to nie to, psuje się gdzie indziej

@krzysiek626: to nie jest przyczyna crashu, ale wygląda jakby brakowało pillow. może ja po prostu zaraz zuploaduję ten folder python64 żeby nie było wątpliwości
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 03 Marca 2017, 18:22:47
Czemu nie mogę screenów z symulatora robić, shft+prtScr?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 03 Marca 2017, 18:39:34
widzę że są z tym problemy, wstawiam więc gotowy folder python64: https://milek7.pl/.stuff/eu07exe/python64.tar.xz

@krzysiek626: rozpakuj ten folder ode mnie i sprawdź czy już nie ma błędów z pythonem.
crashuje się w jakimś dziwnym miejscu przy wyświetlaniu displaylist, debugowanie tego trochę zajmie, visual pokazuje coś że sterta się uszkadza. tymczasowo testuj na VBO, powinno działać.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 03 Marca 2017, 18:43:16
Sprawdzę zaraz po skopiowaniu, wywaliło mnie na kaliskiej po 10 minutach symulacji nic nie dotykałem nawet klawiatury. AI. Za to nareszcie mam te crashe to załączam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 03 Marca 2017, 18:49:37
VBO sa tymczasowo wylaczone, wiec tutaj zmiana nie pomoze, i tak bedzie uzywac display lists.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 03 Marca 2017, 18:57:36
nie, na moim buildzie można wybrać vbo
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 03 Marca 2017, 19:00:09
Skopiowałem katalog python64, bałtyk się nie uruchomił. Końcówka z logu:
Player train init OK
Created texture object for "textures\smuga2.tga"
Loading texture data from "textures\smuga2.tga"
Load time: 29 seconds
EVENT LAUNCHED: onstart_zacheta
Multiple passed
EVENT ADDED TO QUEUE: baltyk_p_ms2
EVENT ADDED TO QUEUE: start
i crash w załączniku.
ED:
 Skoro tak, włączę vbo.
D2:
 Włączenie VBO skutkuje uruchomieniem Bałtyku. Nadal z schowka wklejam ciemność. Tylko w symulatorze, z pulpitu mam... pulpit.

ED3:
Psuje, na VBO zamiast szyn mam drewniane belki. Przechodzimy na epokę kamienną;)
Poważnie tak mam na Kaliskiej, w bałtyku mimo że odpaliłem nie sprawdzałem. Na gdzinę odpuszczam, nadal mam ciemność ze schowka.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 03 Marca 2017, 19:37:52
Wersja tmj 170303:
-Klawisz pause nie pauzuje. Escape tak.
-Przy pauzie nie mogę zmienić okna. EU07 zostaje na wierzchu, choć jest nieaktywne. Bez pauzy zazwyczaj się zmienia, choć i na borlandzie miałem z tym niekiedy problem.
-Strasznie ostre jest bujnięcie kamerą gdy wchodzi składowa prostopadła przyspieszenia. Odchył też, jakby maszynista miał z fotela spaść.
-Domyślna symkowa 10:30. Niebo dynamic stratus. Światło mocno niebieskie, momentami skaczące do bielszego na kilka minut. Wpis światła ma tu jakieś znaczenie?
-Znikają trójkąty o środku ~kilometr z boku kamery. Patrz załącznik. Jeziorko na Drawinowie po. Grabówek Lachy.
-Przypominam o wyłączonym modyfikatorze oświetlenia przez otoczenie we wpisie trajektorii. W tunelu widno. Przyciemnienie ścian (kolor materiału node triangles) też średnio sobie radzi z oświetleniem kierunkowym.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 03 Marca 2017, 19:45:42
-Domyślna symkowa 10:30. Niebo dynamic stratus. Światło mocno niebieskie, momentami skaczące do bielszego na kilka minut. Wpis światła ma tu jakieś znaczenie?
Wpis, raczej nie. Bez screenow trudno sie wypowiedziec, bo ta uwaga o skokach brzmi dziwnie, ale swiatlo jest niejako rozdzielone na dwa elementy -- slonce (ktore ma kolor swiatla slonecznego) i swiatlo zalamane/odbite od atmosfery, ktore ma aktualny kolor nieba, z reguly w ciagu dnia o zabarwieniu niebieskim, rano/pod wieczor rozowe/zolte. Powoduje to, ze obiekty oswietlone bezposrednio sa jasniejsze i bardziej "biale", natomiast te nie obrocone w strone slonca otrzymuja w wiekszym stopniu swiatlo odbite, i moga wydawac sie bardziej niebieskie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: queuedEU w 03 Marca 2017, 19:54:20
Potrzebny kod na robienie skrinszotow? :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 03 Marca 2017, 19:57:39
Może zmieniała się pozycja słońca/składu i stąd różnica, ale efekt był skokowy, jakby słońce chmura zasłoniła. :P Ciężko zmianę na screenie złapać. Może w przyszłości bo dziś już nie mam cierpliwości się gapić. AI kończy przejazd. Niebo lazurowe, jak w Saint Tropez, więc pewnie stąd tak silne niebieskie zabarwienie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 03 Marca 2017, 19:58:23
O esc pisalem, ze byl do czego innego kiedy tmj pisal, ze przywrocil paze. Z kolorami nieba i atmo.... Odpal dzisiejsze wrzutki od Milk7 i porownaj. Bujania nie zaprzecze i nie potwierdze, zwyczajne 20170303 nie testowalem, posluzylo jedynie do eliminacji bledu uruchamiania exe na nowj instalacji windowsa. Ale z poprzednich wersji polecam przejechac sie kiblem i siodemka, byk jest do poprawy, tylko czy to najlepsza pora. Wyobrazam sobie ustabilizowac wczytywanie scenerii, odpalanie aplikacji i zwrocenie uwagi na latwosc instalacji paczki exe plus potrzebne biblioteki. Do wiekszych testow wydac trzeba jakis oficjalny pacz do pc z exekiem c++.
Ps, Antek, odpal na starym exe ten wagon w baltyku i na td. Jak zrobisz sceeny bedzie podobny efekt. Nie twierdze ze jest dobrze, ale mam inne priorytety.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: queuedEU w 03 Marca 2017, 21:21:22
Stele, ty moze miales jakis problem z kompilowaniem po dodaniu tych unitow od zooma? (sccreen.cpp). Mam na mysli borladoskie exe.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 03 Marca 2017, 21:33:19
Q ty miales kilka fajnych ficzerow podziel sie z nimi. Lusterka dym ogien itd... Jak tam moj obiecany plug?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 03 Marca 2017, 21:45:13
Odpaliłem ostatnie exe, scenariusz drawinowo_noc. I mam gwiazdy na terenie i peronach.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: queuedEU w 03 Marca 2017, 21:50:35
@EP08_015: za rok bede mial wiecej czasu na ficzery. Zreszta lepiej poczekac az sie wyklaruje fumkconalnosc exe i dopiero wtedy cokolwiek z bajerow dodawac - wtedy tez byc lepsze modele zaczna sie pojawiac.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 03 Marca 2017, 21:51:38
Stele, ty moze miales jakis problem z kompilowaniem po dodaniu tych unitow od zooma? (sccreen.cpp). Mam na mysli borladoskie exe.
Nie kompilowałem. Czekało sobie na wenę do ogarnięcia i nim ta naszła wypadł Borland.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: queuedEU w 03 Marca 2017, 21:53:43
To dobrze, bo to raczej bedzie trzeba przystosowac do VC -  chociazby AnsiStringi wywalic, ale pewnie nie na tym sie skonczy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 03 Marca 2017, 22:37:52
Kaliska obawiam sie laduje sie u mnie normalnie na najnowszej wersji, nie wykazuje bledow ani nic :/
Naprawiłem u siebie, przy kopiowaniu paczki zrobiły się jakieś braki w katalogu dynamic. Ciekawe, utykało stojąc w nieskończoność bez żadnego komunikatu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 03 Marca 2017, 22:38:19
Odpaliłem ostatnie exe, scenariusz drawinowo_noc. I mam gwiazdy na terenie i peronach.
u mnie to w ogóle gwiazd nie ma...

tak przy okazji, dodałem robienie screenshotów pod F11. zapisują się do folderu screenshots (należy ręcznie utworzyć)
https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng32-84f54db1.zip
https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng64-84f54db1.zip
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 03 Marca 2017, 22:47:28
Przydałby się drugi komputer, nie ma szansy do jutra, aby sprawdzić foty z nowego ficzera (u Q był). Napisz jaki format i jaka kompresja, co by na forum jako załączniki można dawać.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 03 Marca 2017, 22:51:10
png, bo bezstratne. Każdy może sobie później przekonwertować na to co chce, ale jak jest potrzeba to mogę dodać jutro dodać inne (jpeg, czy tam jpeg2000)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: queuedEU w 03 Marca 2017, 22:53:21
@Milek, ja w module od screenshotow mialem taka koncepcje, ze zapisywalo mi do folderow definiowanych w eu07.ini.  Byl tam glowny katalog do sshotow i podkatalog. Podkatalog mial sluzyc jako katalog tematyczny gdzie u mnie byl to poprostu rok, czyli np SCR/17/. Do wyboru bylo kilka formatow do ktorych mogl byc zrzucany obraz a byly to tga, bmp i jpg. Oczywiscie najbardziej praktyczny byl jpg, a dodatkowa funkcja bylo zapisywanie exif a w nim informacje o autorze, data, FoV, wspolrzedne wykonania i inne dane o scenerii takie jak ustawienia atmo, oswietlenia itp. Warto o tym pomyslec.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 03 Marca 2017, 23:56:32
Odpaliłem ostatnie exe, scenariusz drawinowo_noc. I mam gwiazdy na terenie i peronach.
Masz moze jakis screenshot? Obawiam sie, ze u mnie wyswietla gwiazdy gdzie trzeba ;/

u mnie to w ogóle gwiazd nie ma...
Do wyswietlania gwiazd potrzebny jest plik skydome_stars.t3d w katalogu models, byl dolaczany pare razy do paczki, powinien byc w tych troche wiekszych.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 04 Marca 2017, 00:08:00
png, bo bezstratne. Każdy może sobie później przekonwertować na to co chce, ale jak jest potrzeba to mogę dodać jutro dodać inne (jpeg, czy tam jpeg2000)
Pobralem wersje 32 bitowa i zainstalowalem w pacze na wczoraj postawionym xp. Musialem doinstalowac MS 2015. Screeny sa, zapis w png jak mowiles, zajmuje okolo 1.5mb przy zalozeniu 1280*1024. Brakuje klikniecia informujacego. Jak wprowadzisz jpga bedzie klawo jak cho......
@tmj, 20170304 odpalone bez najmniejszych problemow, nic nie zepsules.:) Tez na nowym xp.
Testy z jazd jutro po obiedzie. 20170303, wykonalem 3 jazdy na baltyku i jedn na Kaliskiej. Nie mam zadnych uwag. Nie psujcie tak dalej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 04 Marca 2017, 00:11:55
Dla porzadku, 170304 ma poprawiona komunikacje przez WM_COPYDATA. Troche jest tez przeorganizowana glowna petla uaktualnienia symulacji, ale tego akurat nie widac.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 04 Marca 2017, 00:19:34
Odpaliłem ostatnie exe, scenariusz drawinowo_noc. I mam gwiazdy na terenie i peronach.
U mnie 20170303 noc w Drawinowie jest gwiaździsta. Załącznik
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Paul w 04 Marca 2017, 00:48:57
Crash na 170304. Wywala się po zakończeniu wczytywania, zanim cokolwiek się wyświetli. Na 170302 efekt podobny, natomiast 170301 działa. Sugerowana przyczyna w starym sprzęcie prawdopodobna - uruchamiane na HP 550. Jutro sprawdzę na czymś nowszym. Przy okazji, log.txt twierdzi że "Compilation 2017-01-10". Można by zaktualizować lub to usunąć.

Podpis problemu:
  Nazwa zdarzenia problemu: APPCRASH
  Nazwa aplikacji: eu07++170304.exe
  Wersja aplikacji: 17.0.1175.483
  Sygnatura czasowa aplikacji: 58b9ee55
  Nazwa modułu z błędem: ig4icd32.dll
  Wersja modułu z błędem: 8.14.10.1930
  Sygnatura czasowa modułu z błędem: 4aba6fc2
  Kod wyjątku: c0000005
  Przesunięcie wyjątku: 00066b66
  Wersja systemu operacyjnego: 6.1.7601.2.1.0.256.48
  Identyfikator ustawień regionalnych: 1045
  Dodatkowe informacje 1: 0a9e
  Dodatkowe informacje 2: 0a9e372d3b4ad19135b953a78882e789
  Dodatkowe informacje 3: 0a9e
  Dodatkowe informacje 4: 0a9e372d3b4ad19135b953a78882e789
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 04 Marca 2017, 01:26:15
Interesujace, wylecialo na probie renderowania modelu nieba cgskj_overcast027.e3d, ktory z jakiegos powodu wywala blad przy ladowaniu. Przyjrze sie.

edit: ok, poprawione. Glupi blad i nie wiem jakim cudem do tej pory sie przesliznal (chyba kombinacja rzadkiego dodawania rozszerzenia do nazwy modeli, i uzywania statycznych modeli nieba) ale teraz powinno byc dobrze. Przynajmniej pod tym wzgledem :d
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 04 Marca 2017, 06:49:16
Test na zwierzyniec_transport. Zaraz po otrzymaniu wyjazdu jakaś drezyna rozpędzona do 300km/h zderzyła się ze mną czołowo. ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 04 Marca 2017, 09:28:42
Interesujace, wylecialo na probie renderowania modelu nieba cgskj_overcast027.
edit: ok, poprawione. Glupi blad i nie wiem jakim cudem do tej pory sie przesliznal
Przeslizgnelo sie, bo ja katuje Kaliska, Baltyk i Quarka. Czasem Zwierzyniec i Drawinowo. Taki blad jak u @Paula mialem na Baltyku. Wywalalo na exe od Milka, pomoglo wlaczenie VBO. Za malo nas aby szybko ogarnac wszystkie scenerie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 04 Marca 2017, 09:48:02
Interesujace, wylecialo na probie renderowania modelu nieba cgskj_overcast027.e3d, ktory z jakiegos powodu wywala blad przy ladowaniu. Przyjrze sie.

edit: ok, poprawione. Glupi blad i nie wiem jakim cudem do tej pory sie przesliznal (chyba kombinacja rzadkiego dodawania rozszerzenia do nazwy modeli, i uzywania statycznych modeli nieba) ale teraz powinno byc dobrze. Przynajmniej pod tym wzgledem :d
wrzuć źródła.
ps: a nie, jak przy ładowaniu to mi tego nie potrzeba
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 04 Marca 2017, 09:53:10
Mam sugestię, żeby wszystkie utils i tools wrzucić do jednego pliku. Dawniej było mctools, potem każdy robił własny plik i będzie straszne zamieszanie. Może jednak to połączyć co? Proponuję wykorzystanie pliku usefull.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Paul w 04 Marca 2017, 13:35:45
edit: ok, poprawione.

Na starym komputerze problem nie ustąpił, nadal crash na tym dll. Może faktycznie problem sprzętowy, a przez przypadek przy sprawdzaniu wylazło coś innego.

Sprawdzałem na drugim, i komunikacja WM_COPYDATA działa jak należy. Urządzenia się nastawiają, zajętości działają, można nastawiać przebiegi i jeździć. Jednak po wyświetleniu sygnałów zezwalających na jazdę pociągową na niektórych semaforach EU07 się wysypuje - konkretnie C_E, D_E, D_F w anp_test, prawdopodobnie inne z tymi samymi incami też. To są zdaje się semafory które miały być powiązane z sbl, z uwagi na umieszczenie logiki sbl w SCS ja ich używam trochę inaczej, może coś trzeba poprawić w inc ale chyba nie powinno to skutkować sypaniem się. Manewrowe, Sz na tych semaforach działają poprawnie, inne semafory i obiekty innych typów również. Po próbie wyświetlenia problematycznego sygnału EU07 jeszcze odsyła potwierdzenie przyjęcia eventu, po czym się przewraca, w oknie EU07 nie widać już wyświetlenia sygnału. W załączniku log i dmp, najpierw nastawiłem przebieg od B_F, po chwili była próba od C_E.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 04 Marca 2017, 13:53:45
Z tego co widze, wywraca sie na probie logowania nieistniejacych parametrow testowanego eventu, ale prawdopodobnie bledem jest juz to, ze te parametry nie istnieja, trudno powiedziec.
Czy moglbys podac mi jakas idioto-odporna instrukcje jak nastawiac przebiegi? Robie tak:
- uruchamiam SNSg, wybieram scenariusz anp_test
- uruchamiam symulator, z anp_test.scn i aktywna opcja multiplayer
- w okienku SCS ikona "EU07" podswietla sie na zielono
- klikam na semafor wyjazdowy, np A_H a nastepnie podwojne klikniecie (albo opcja 'koniec' z menu pod prawym) na docelowym, np B_E

... i dostaje komunikat "nie mozna ustawic przebiegu" albo podobny. Co robie zle, i co trzeba zrobic, zeby poszlo?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Paul w 04 Marca 2017, 13:59:01
Według tego co napisałeś, to robisz dobrze, tylko prawdopodobnie wybierasz zły semafor końcowy - trzeba zaznaczyć kolejne, bez pominięcia pośrednich. Dla nastawienia od A_H kliknij podwójnie na B_A. A jak chcesz do B_E za jednym zamachem, to kliknij pojedynczo na A_H, pojedynczo na B_A i podwójnie na B_E.

Uprzedzając pytanie, dla wyjazdu na szlak z sbl trzeba podwójnie kliknąć na żółtą strzałkę blokady zamiast na następny semafor.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 04 Marca 2017, 14:08:04
Ahh ok, myslalem ze wystarczy startowy i docelowy, a program sobie sam ustali przebieg "od-do". OK, sprobowalem tak jak mowisz i poszlo. Zobacze czy uda sie wylapac zrodlo wysypow.

edit: ok, wyglada to tak, ze symulator dostaje polecenie by porownac dane dla eventu np. d_em-s2 z jakimis parametrami, ktorych oczekuje w swoich danych, ale tych danych tam nie ma. Moge ustawic tutaj jakis test, zeby w takiej sytuacji dawal komunikat o bledzie do logu i nie popelnial samobojstwa, ale czy jest mozliwe, ze sytuacja spowodowana jest jakims krzakiem of strony .scn/.inc, a nie symulatora jako takiego? Czy na wersji Borlandowej dziala to normalnie?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Paul w 04 Marca 2017, 15:21:57
Ten semafor to SSd5zpcpbIW24.inc, jest tam jeszcze kilka podobnych. Problem w tym, że normalnie w jego wpisie podaje się nazwę następnego semafora (p7), i wyświetlany sygnał jest uzależniany od komórki pamięci następnego semafora. Ponieważ zależności sygnałowe realizuje SCS, w miejscu (p7) znajduje się none, i symulator próbuje sprawdzać komórkę none_sem_mem. W starych wersjach brak komórki był ignorowany i dawało się sterować sygnałami. A skoro działało, to tak zostało to rozwiązane, dzięki czemu nie trzeba było dodatkowo mnożyć inców semaforów. Można to oczywiście zmienić i dorobić wersje semaforów bez uzależnień.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 04 Marca 2017, 16:02:01
Od exe eu07++170331 nie działa odbieranie informacji przez UART z zewnętrznego mikrokontrolera zrobione przez @maćka001 i dodane od exe eu07++170226, tzn. nie da się sterować nastawnikiem, hebelkami itd. Dodatkowo, jeśli dałoby zrobić tak, aby ta komunikacja działała również wtedy, kiedy exe jest oknem w tle (przy wyłączonej pauzie, gdy w tle), to z użyciem SCSa można by na jednym komputerze obsadzić dwie osoby - maszynistę sterującego jazdą pociągu z rzeczywistego pulpitu lokomotywy i dyżurnego sterującego ruchem z aktywnego okna SCSa na drugim monitorze. Dałoby się to zrobić? Właśnie kiedy chciałem to sprawdzić, zauważyłem powyższy błąd.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Paul w 04 Marca 2017, 16:16:14
Powinno się udać, wygodniej jednak będzie SCS uruchamiać na drugim komputerze - przyszłościowo przewidziana jest taka możliwość (w aktualnie udostępnionej wersji nie zadziała, bo potrzebna jest dodatkowa aplikacja działająca jako serwer komunikacji sieciowej).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 04 Marca 2017, 16:20:19
Właśnie chodzi mi o to, żeby była też możliwość sterowania z jednego komputera. Trzeba tylko zrobić tak, żeby komunikacja z mikrokontrolerem przez UART działała też wtedy, kiedy okno exe jest w tle.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: art72 w 04 Marca 2017, 19:41:40
Najnowsze exe (170304b) pozwoliło mi zrobić rundkę w obie strony dziewiątką po Drawinowie.

Mam tylko kilka uwag:
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 04 Marca 2017, 20:02:18
Dzisiaj fps nie przekraczał 23
Sprawdz jesli mozesz, czy sytuacja poprawi sie po wpisie do .ini
vsync no
Cos tam jest nie tak na linii glfw/przelaczanie buforow ekranu/byc moze vs2013, i rezultatem jest tego rodzaju spowolnienie gdy czestotliwosc odswiezania spada ponizej czestotliwosci odswiezania ekranu, czyli zazwyczaj 60.

Zubozenie scenografii itp moze byc z tym powiazane -- renderer obniza ilosc detali i/lub zakres widocznosci przy niskim framerate.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 04 Marca 2017, 20:04:19
Ograniczanie zasięgu było u nas w kodzie i nigdy nie było tak drastyczne. Przy fps<20 była odległość rysowania na kilometr, ale nie znikały trójkąty z boku.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 04 Marca 2017, 20:15:46
Jadę właśnie w Drawinowie EP09, FPS mam prawie 60, mam inny kłopot, zamiast szyb jest kalka techniczna. Załączniki.
Ja jadę po Drawinowie z paczki całościowej. To modyfikowane w tej chwili, może nie być skończone, stąd powstrzymałbym się od oceniania braków w tej scenerii.
170304b
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 04 Marca 2017, 20:19:32
Ograniczanie zasięgu było u nas w kodzie i nigdy nie było tak drastyczne. Przy fps<20 była odległość rysowania na kilometr, ale nie znikały trójkąty z boku.
Ale art72 pisze, ze wygladalo dokladnie tak samo, jak w .exe z paczki calosciowej? :)

Co do zaniku funkcjonowania komunikacji, czy moze miec to zwiazek ze zmianami, jakie Maciek wprowadzil w ostanim uaktualnieniu? Pododawal tam chyba kila roznych przelacznikow do .ini, moze trzeba je ustawic? Pytam bo niestety nie jest to cos, co moge sensownie przetestowac -- funkcja komunikacji jest wywolywana regularnie, ale nie mam Pokeys ani niczego takiego, wiec exe nie ma sie z czym komunikowac.

edit:
Jadę właśnie w Drawinowie EP09, FPS mam prawie 60, mam inny kłopot, zamiast szyb jest kalka techniczna. Załączniki.
Ale EP09 to chyba tak akurat zrobiona jest? Na exe z paczki przezroczystosc jest mniej wiecej ta sama, tylko kolor mniej niebieski, bo oswietlenie jest biale:

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 04 Marca 2017, 20:28:33
U mnie nie wyglądało tak na exekach borlandowskich. Może wydajność spadła i ucina bardziej, ale z tymi jeziorami nie było problemu gdy przy nich majstrowąłem. Sprawdzę jak po wyłączeniu vsync.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: art72 w 04 Marca 2017, 20:29:12
@tmj, po wpisie do pliku .ini sytuacja wróciła do normy: podskoczył fps i poszczególne elementy scenerii ładnie się wczytują.

Nie napisałem o jeszcze jednym bugu. Mianowicie jakieś 100m przed lokomotywą podkłady są brzydko rysowane; tak, jakby kilka z nich oddziaływało wzajemnie na siebie w ramach "interferencyjnej podkowy". Wspomniane podkowy są skierowane ramionami na zewnątrz toru, zazwyczaj występują w parze i widać je na wszystkich torach.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 04 Marca 2017, 20:36:07
Nie napisałem o jeszcze jednym bugu. Mianowicie jakieś 100m przed lokomotywą podkłady są brzydko rysowane; tak, jakby kilka z nich oddziaływało wzajemnie na siebie w ramach "interferencyjnej podkowy". Wspomniane podkowy są skierowane ramionami na zewnątrz toru, zazwyczaj występują w parze i widać je na wszystkich torach.
Dla pewnosci przydalby sie screenshot :) Sprobuj dac w .ini
anisotropicfiltering 16
i zobacz czy sytuacja sie polepszy? To brzmi troche jak efekt mory, i bez solidnego filtrowania bedzie widoczne na elementach takich jak podklady.

Aha, sprawdzilem przy okazji EP09, i nacisniecie shift+U zapala u mnie wszystkie 3 swiatla ale kolejne nacisniecia przelaczaja miedzy zdefiniowanymi kombinacjami, wiec moze przypadkiem wcisnales shift + U wiecej niz raz?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 04 Marca 2017, 20:44:23
Nadal mam 60fps bez wpisów do ini. Synchronizacja monitora włączona. Czemu mam tak wysoki fps? Skąd taka różnica u mnie i u @art?
ED:
Podkowy na podkładach, załącznik, miejsce około słupka hektometrowego. Screen zrobiony w czasie jazdy 160/km/h
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 04 Marca 2017, 20:47:15
Prawdopodobnie na twoim sprzecie symulator jest w stanie wygenerowac wiecej niz 60 fps, wiec synchronizacja dziala jak trzeba. Jesli jestes ciekaw, tez wpisz vsync no i zobacz ile wtedy wyciagnie ;)

edit: "podkowy" sie zgadzaja, taki efekt pojawi sie przy waskich rownoleglych liniach, a te z kolei pojawiaja sie gdy teksturowana plaszczyzna jest pod duzym katem do kamery. W oryginalnej wersji symulatora bylo to do pewnego stopnia uktryte silnym rozmyciem tekstur w odleglosci wiekszej niz czubek nosa.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 04 Marca 2017, 21:16:13
Wersja 3.03.17 @tmj.
Na Drawinowie wyszedł problem z asynchronami. Traxx AI nie rusza. Zadajnik na maxa i brak siły. Przetestuję osobno na TD.
Po wyłączeniu vsync jeziorko bez zmian. 108 fps, 92 wyświetlane sektory, trójkąty nadal znikają jak się na patrzy na ich środek. Nie ruszałeś czegoś przy automacie dzielącym duże node traingles? Tam reszta terenu jest w e3d, a woda i lasy jako przezroczyste zostały w node trangles i są inaczej traktowane.
-----
Na TD lata. Odpalę się w nim na Drawinowie od początku i zobaczę co AI wyrabia.
Przypominam o braku dźwięku falownika (rwent) w asynchronach.

Startuje pod wjazdem od Grabówka. W rozkładzie ma w nim postój. Staje na W4 i coś mu odcina jazdę. Może otwiera "drzwi" na w4 i odcina jazdę? Sprawdzę na 482 i jakiegoś ezt z drzwiami na c++.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 04 Marca 2017, 21:33:20
Nie ruszałeś czegoś przy automacie dzielącym duże node traingles?
W ogole tego nie ruszalem bo tam jest zakrecone jak ruski sloik, ale nie wykluczam ze cos jest skopane. Z tym, ze poniewaz nie wiem jak to dziala, to szanse zebym to rozgryzl i poprawil sa raczej mizerne.
Docelowo i tak wolalbym przerobic teren na standardowy system siatek, chocby dlatego ze to duzo wygodniejsze w edycji i zabaw z teksturowaniem. Tzn przy zalozeniu, ze uda sie ewentualnie wprowadzic edycje scenerii z wnetrza exe.

Co do Traxxa to zgadza sie, na W4 standardowo otwiera drzwi, ale juz ich nie zamknie bo ma pod te komendy podpieta obsluge wyswietlaczy. Taki efekt uboczny uzywania tych samych klawiszy do wiecej niz jednej funkcji ;)  Zmodernizowany ET22 ma podobnie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 04 Marca 2017, 21:37:44
Ale traxx nie ma wyświetlaczy pod drzwiami od wczesnej bety. Wszystko na ekranach jest pythonem robione.
Chodzi mi o ai kierownika, próbujące otwierać drzwi na W4 i fizykę asynchronów, która odcina jazdę przy otwartych drzwiach. Gdzieś brakuje sprawdzenia czy jakiekolwiek drzwi są i się blokuje.
Te same pliki pojazdu, exe 472 borlandowskie. Nic się nie blokuje. Po odhamowaniu nadal ma jazdę.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 04 Marca 2017, 21:45:00
Nie pamietalem dokladnie, drzwi i wyswietlacz jest chyba w modernizowanej ST45. Problem z Traxxem jest troche inny, byl juz dyskutowany:

Cytuj
Przy okazji, jest taki dosc ogolny problem logiczny na styku otwierania drzwi I obslugi ekranow -- uzywaja one tych samych klawiszy, co prowadzi do roznych sytuacji, od smiesznych takich jak AI wlaczajaca/wylaczajaca ekran zamiast otwierac drzwi na stacjach (w ST45), po bardziej powazne jak 186-2 otwierajaca drzwi na przystanku, i nie bedaca w stanie jechac dalej, bo dopoki drzwi sa otwarte wlaczony jest hamulec dynamiczny, co uniemozliwia zwiekszenie ciagu, a drzwi zamknac nie moze, bo nie ma tego w konfiguracji :d
Sprowadza sie to do tego, ze dopoki dzwi sa otwarte, to hamulec dynamiczny jest zalaczony, a AI nie wysle komendy zamkniecia drzwi dopoki nie ruszy z miejsca (coby nie wachlowac nimi przy kazdym sprawdzeniu sytuacji) a nie ruszy z miejsca dopoki hamulec jest zalaczony... i takie bledne kolo.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 04 Marca 2017, 21:48:23
Wyświetlacz jako lampka drzwi był w ET22, ale to chyba też zostało już poprawione. Pseudodrzwi ma na pewno ET42 jeszcze, bo tam cała sygnalizacja pulpitu i klaskon są pod to podpięte.
Powtarzam, Traxx nie ma wpisu drzwi w wersji release. Ten cytat odnosił się do wersji roboczej, przed zrobieniem mu ekranu na pythonie, gdy istotnie był włączany jako kontrolka drzwi.
Wstawiłem w to miejsce akł. Zatrzymał się otworzył drzwi i zamiast zamknąć dał zadajnik na 100%. A tu nie ma żadnego szamaństwa w fizyce. Proteza na trzaskanie drzwiami jest zbyt protetyczna, skoro pojazd z blokadą jazdy nie zamknie drzwi przed ruszeniem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 04 Marca 2017, 21:56:41
Chodzi mi o ai kierownika, próbujące otwierać drzwi na W4 i fizykę asynchronów, która odcina jazdę przy otwartych drzwiach.

IMO w przypadku TRAXXa, to póki nie ma w symulatorze wagonów PP radziłbym nie uzależniać blokady napędu od drzwi. Ba, na PP też można TAV wyłączyć i mieć samo SAT (kontrola drzwi bez blokady napędu) lub TB0 (samoczynna blokada drzwi przy V>0 podobnie jak w blokada drzwi w klasycznych wagonach).

EDIT: A jeżeli to jest kwestia AI kierownika bez względu na tabor, to tak być też nie powinno ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 04 Marca 2017, 22:06:36
@tmj, bylem nie dosc precyzyjny, szyby w dziewiatce takie sa. Nie mamy dobrego pomyslu na nie. Bylem nieprecyzyjny i wyszlo ze to wina exe, nic z tych rzeczy. Dalszy ciag, jutro.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Tomnord15 w 04 Marca 2017, 22:27:50
Ostatnia aktualizacja zepsuła możliwość wybierania nieba, przynajmniej na Quarku. Dotychczas robiłem tak, że usuwałem wpis movelight i dzięki temu mogłem jeżdzić w dzień. Po dzisiejszej aktualizacji mam cały czas noc.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 04 Marca 2017, 22:32:25
Odpaliłem swoją scenerię, exe mi się wywaliło po jakiś 7 minutach, oznak szczególnych co do przyczyn brak - w załączeniu crashdump.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 04 Marca 2017, 22:41:44
Proteza na trzaskanie drzwiami jest zbyt protetyczna, skoro pojazd z blokadą jazdy nie zamknie drzwi przed ruszeniem.
Chyba znalazlem alternatywe, ktora takze dziala, ale nie blokuje Traxxa czy jemu podobnych (a przy okazji teraz AI najpierw zamyka drzwi a potem rusza, zamiast jak do tej pory odwrotnie) W szybkim tescie na TD bylo ok, do dokladniejszego sprawdzenia bedzie w nastepnym uaktualnieniu.

Ostatnia aktualizacja zepsuła możliwość wybierania nieba, przynajmniej na Quarku. Dotychczas robiłem tak, że usuwałem wpis movelight i dzięki temu mogłem jeżdzić w dzień. Po dzisiejszej aktualizacji mam cały czas noc.
Wpis movelight okresla tylko dzien roku, a nie godzine symulacji, ktora o ile sie nie myle kontrolowana jest wpisem w sekcji time (bez tego wpisu wartosc domyslna to 10:30)  Ostatnia aktualizacja naprawila ladowanie niektorych plikow .e3d, wiec moze w tym scenariuszu jest takie wlasnie niebo (zdefiniowane w sekcji sky) ktore teraz laduje sie i zakrywa dynamiczne 'dzienne' niebo ktore jest 'pod spodem'?

edit:
Odpaliłem swoją scenerię, exe mi się wywaliło po jakiś 7 minutach, oznak szczególnych co do przyczyn brak - w załączeniu crashdump.
Wylecialo na probie odczytu parametru z RList, ale trudno tu powiedziec cos wiecej. Byc moze do sprawdzenia jest plik .fiz pojazdu, ktory byl za to odpowiedzialny.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 04 Marca 2017, 22:50:53
Trax na Drawinowie ruszył i na mój gust jedzie dobrze. Załącznik.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 04 Marca 2017, 22:55:56
W borlandowskich wpis movelight w ogóle włączał dynamiczne niebo. Bez niego było statyczne o parametrach z wpisów light&atmo.

Krzysiu, na screenie to masz wyłączone AI i jesteś przed zatrzymaniem na W4.

Jeszcze detal. Uruchamiam w trybie pełnoekranowym. Jeśli podczas ładowania zmienię okno, okno symulacji nie odświeża się do czasu załadowania. Jest nieaktywne, nie daje się przywrócić na wierzch. We wczesnych c++ chyba to działało, ale nie ma co się babrać, bo w funkcjonalności nie wadzi.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 04 Marca 2017, 23:10:17
To sie chyba wiaze z tym, ze okno symulatora odswieza sie tylko kika razy, kiedy zmieniaja sie napisy o postepie ladowania. Moze kiedys pojawi sie tam normalnie uaktualniany ekran, wtedy powinno byc jak trzeba :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 04 Marca 2017, 23:12:00
Na potrzeby screena ai wylaczylem, ale to jeszcze sprawdze. W Quarku wywalilem wszystkie wpisy i zaladowalem scenerie, co bym nie zaznaczyl mam ciemnosc. Bezposrednie wpisy nieba i atmo w scenerii nic nie daja, zawsze mam ciemno. To samo z wybieraniem w rainsted. No to odpalilem na tym z paczki, jest widno. Zreszta ta funkcjonalnosc, wybor nieba w rainsted zrobila sie bardziej skomplikowana odkad jest dynamiczne niebo.
Ed:
Potwierdzam, 170304b cos przeszkadza aby trax ruszyl spod w4 w Drawinowie. Wczesniej bylo dobrze, ale nie pamietam na ktorej wersji exe.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 05 Marca 2017, 00:52:42
Dzisiaj fps nie przekraczał 23
Sprawdz jesli mozesz, czy sytuacja poprawi sie po wpisie do .ini
vsync no
Cos tam jest nie tak na linii glfw/przelaczanie buforow ekranu/byc moze vs2013, i rezultatem jest tego rodzaju spowolnienie gdy czestotliwosc odswiezania spada ponizej czestotliwosci odswiezania ekranu, czyli zazwyczaj 60.

Zubozenie scenografii itp moze byc z tym powiazane -- renderer obniza ilosc detali i/lub zakres widocznosci przy niskim framerate.
Ale vsync tak działa - jak nie wyrobi w czasie odświeżania, to później przycina do f/2, później f/3, itd.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 05 Marca 2017, 01:53:12
Niby tak, ale do tej pory w exe go nie bylo, wiec to latwo zauwazalna zmiana. Byc moze vs2015 optymalizuje troche lepiej, bo z tego samego ujecia w Kaliskiej fps (przy vsync off) jest na poziome 61-62 czyli dosc zeby sie jeszcze wyrobic bez opoznien, ale kompilacja z vs2013 daje 58-59, czyli w efekcie ~30. Wiec majac do wyboru prawie 30 fps wiecej albo vsync, coz ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Tomnord15 w 05 Marca 2017, 10:56:42
Próbowałem uruchomić dzisiaj najnowszą wersję EP09 klasyczną na najnowszej wersji Drawinowa w misji Drawinowo noc. Pantografy się podnoszą, można uruchomić baterię, ale rozrząd, przetwornica i sprężarka nie działają. Najnowsze exe ze wszystkimi bibliotekami. W załączeniu log oraz errors. Plik crushdump nie generuje się.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 05 Marca 2017, 11:07:54
Crashdump jak sama nazwa wskazuje, generuje sie przy nieoczekiwanym zakonczeniu programu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 05 Marca 2017, 11:08:57
Tomnord: http://eu07.pl/forum/index.php/topic,28159.msg443641.html#msg443641 (http://eu07.pl/forum/index.php/topic,28159.msg443641.html#msg443641)
klika postów wyżej, to samo exe. Podaj numer loka.
OK, 043 podawanie:
Cytuj
Najnowsza
jest mało precyzyjne jak toś nie pamięta która, to po logach trzeba szukać.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Tomnord15 w 05 Marca 2017, 11:10:55
Numer EP09-043, 104E_4. Najnowsza klasyczna wersja.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 05 Marca 2017, 11:53:24
U mnie ona jeździ, sprawdzałem też 046 choć to tylko zmiana tekstury.
ED:
Moim zdaniem nie załączasz WS, za krótko trzymasz [M]. Trzymaj około 5 sekund.
ED2:
Czy istnieje wpis blokujący zapis do pliku $.scn? W Rainsted trzeba to zaznaczać za każdym razem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 05 Marca 2017, 15:14:37
Wylecialo na probie odczytu parametru z RList, ale trudno tu powiedziec cos wiecej. Byc moze do sprawdzenia jest plik .fiz pojazdu, ktory byl za to odpowiedzialny.
Tylko, jak ustalić, który to pojazd... Oki, zobaczymy, może z czasem samo wyjdzie.

Z innej beczki - da radę zrobić coś z tym niebieskim cieniem? Patrzyłem przed chwilą za okno i nijak nie widzę, żeby cienie przy słonecznej pogodzie jak dzisiaj były niebieskie... Obecnie w symulatorze wygląda to niezbyt realnie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 05 Marca 2017, 15:58:54
Mozna zmniejszyc efekt, chociaz z drugiej strony zmniejszy sie tez wplyw nieba porannego/wieczornego. Poeksperymentuje i zobaczymy.

W miedzyczasie, uaktualnienie, glownie z poprawkami:

- poprawiona logika zamykania drzwi przy odjezdzie, powinna pomoc na klopoty z traxxem itp.
- poprawiona komunikacja przez copydata, przywrocona wspolpraca z SCS
- uporzadkowana nieco obsluga kamery w kabinie, poziom drgan powinien byc teraz niezalezny od fps, w praktyce znaczy to, ze przy niskim fps bedzie sie mniej rzucac. Tutaj nalezy zwrocic uwage, ze poziom drgan zalezy tez od wpisow w pliku bodajze .mmd  Obecny poziom rzucania dobrany jest glownie na podstawie EU07/EN57, ale niektore lokomotywy maja w swoich konfigurowacjach znacznie silniejszy efekt.
- usuniete pare potencjalnych zrodel wysypow

(zalacznik usuniety, bardziej aktualna wersja ponizej)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 05 Marca 2017, 16:13:28
- usuniete pare potencjalnych zrodel wysypow
L053 sluzba tlk dalej wywala.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 05 Marca 2017, 16:23:55
Niestety, ten akurat ma miejsce w sterowniku graficznym, na tyle gleboko ze nawet nie wiadomo skad jest wywolany. Ale sprawdz, czy zaladuje ci teraz Drawinowo bez usuwania EU20?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 05 Marca 2017, 16:24:50
Potwierdzam, załącznik z komunikatem na win XP.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 05 Marca 2017, 16:30:25
Ktory to scenariusz? Bo w starterze sa trzy: l053_calkowo-sluzba-tlk, l053_calkowo-sluzba-tlk-1, l053-day-tlk83202
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 05 Marca 2017, 16:32:23
Mozna zmniejszyc efekt, chociaz z drugiej strony zmniejszy sie tez wplyw nieba porannego/wieczornego. Poeksperymentuje i zobaczymy.
Nie znam się do końca na fizyce atmosfery itp., ale wydaje mi się, że jest tu gdzieś błąd logiczny. Przy świetle dnia jest ono tak mocne, że kolor nieba nie powinien w ogóle mieć na nic wpływu. Z tego co kojarzę z własnych subiektywnych obserwacji ogólna niebieskość świata pojawia się, jeżeli słońce zajdzie za chmury i to też wyłącznie w porze zimowej, gdy jest nisko nad horyzontem. Zatem zanim zaczniemy w to brnąć zastanowiłbym się, czy zastosowana logika ma sens. Może należy to inaczej uzależnić np. właśnie od wysokości słońca nad horyzontem i obecności światła słonecznego (to tak na przyszłość, gdyby słońce zaczęły nam kiedyś chmury przesłaniać)?

Z innej beczki: nowe exe wywala mi trzy dodatkowe błędy. Przykład: "Event wolny_szlak_cal-wila_tor2 missing parameters for conditional_memcompare". Zajrzałem do eventów, a tam:
event wolny_szlak_cal-wilA_tor1 multiple 0.0 zajetosc_mac-wil wolny_szlak_cal-wil_upd condition memcompare * * 901 endevent
event wolny_szlak_cal-wilA_tor2 multiple 0.0 zajetosc_mac-wil wolny_szlak_cal-wil_upd condition memcompare * * 902 endevent
event wolny_szlak_cal-wilA_tor3 multiple 0.0 zajetosc_mac-wil wolny_szlak_cal-wil_upd condition memcompare * * 903 endevent
event wolny_szlak_cal-wilA_tor4 multiple 0.0 zajetosc_mac-wil wolny_szlak_cal-wil_upd condition memcompare * * 904 endevent
event wolny_szlak_cal-wilA_tor5 multiple 0.0 zajetosc_mac-wil wolny_szlak_cal-wil_upd condition memcompare * * 905 endevent
event wolny_szlak_cal-wilA_tor6 multiple 0.0 zajetosc_mac-wil wolny_szlak_cal-wil_upd condition memcompare * * 906 endevent
event wolny_szlak_cal-wilA_tor8 multiple 0.0 zajetosc_mac-wil wolny_szlak_cal-wil_upd condition memcompare * * 908 endevent
Nie widzę tutaj żadnego błędu, więc nasuwa się pytanie, skąd ten błąd się bierze?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 05 Marca 2017, 16:32:59
Drawinowo się uruchomilo. Natomiast nie wyswietla się pojazd eu20. Uruchomienie pojazdu wraz z wagonami powoduje jakiś tryb freefly i same wagony sa. Uruchamiane na td.

Na drugim screnie powinien być skład et22-001+eu20+chlodnie. Exe pomija tego loka przy ladowaniu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 05 Marca 2017, 16:35:16
Ewidentnie coś jest skopane z tym nowym komunikatem - jak pisałem tamtego posta miałem w tle włączony symulator i wypluło mi w międzyczasie do errors.txt prawie całą litanię eventów, w tym eventy dżwiękowe czy sterujące semaforami z plików inc. Przykład:
Event dab_zwr6_jea29_sound+ missing parameters for conditional_memcompare
Event dab_zwr3_jea29_sound0 missing parameters for conditional_memcompare
Event dab_zwr2_jea29_sound- missing parameters for conditional_memcompare
Event dab_zwr1_jea29_sound- missing parameters for conditional_memcompare
Event wil_prz1_zamykaj missing parameters for conditional_memcompare
Event cal-wilb missing parameters for conditional_memcompare
Event paszw_toe_sem_od1n missing parameters for conditional_memcompare
Event paszw_e_sem_sr1n missing parameters for conditional_memcompare
Event wil_tm17_sem_m2n missing parameters for conditional_memcompare
Event wil_k_sem_sr3n missing parameters for conditional_memcompare
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 05 Marca 2017, 16:44:40
Ciekaw jestem tego. EU04 się laduje z kabina. EU20 się nie laduje. ET21 mod i zez oraz 3e się nie laduja. Wszystkie lokomotywy laczy kran knorra ale tylko jedna z nich tzn EU04 jest załadowywana i wyswietlana (a tez nie była wcześniej). Może trzeba jakies fizyki przepatrzeć może one cos powodują? Przy okazji nie naprawiles mi działania tej lampki > i-brake_delay_r: zmcis
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 05 Marca 2017, 16:46:24
Z innej beczki: nowe exe wywala mi trzy dodatkowe błędy. Przykład: "Event wolny_szlak_cal-wila_tor2 missing parameters for conditional_memcompare".
(..)
Nie widzę tutaj żadnego błędu, więc nasuwa się pytanie, skąd ten błąd się bierze?
To wyszlo podczas naprawiania komunikacji z SCS, na poprzedniej stronie: http://eu07.pl/forum/index.php/topic,28159.msg443558.html#msg443558

W duzym skrocie, komunikat odnotowuje probe porownania z nieistniejaca(?) komorka, na wypadek gdyby byl to blad przy tworzeniu trasy, a nie dzialanie zamierzone. O ile dobrze rozumiem, to w wersji oryginalnej symulator zwyczajnie to olewal, i przyjmowal sukces.

Ciekaw jestem tego. EU04 się laduje z kabina. EU20 się nie laduje. ET21 mod i zez oraz 3e się nie laduja. Wszystkie lokomotywy laczy kran knorra ale tylko jedna z nich tzn EU04 jest załadowywana i wyswietlana. Może trzeba jakies fizyki przepatrzeć może one cos powodują?
EU20 u mnie sie laduje, ale bez kabiny. Myslalem ze to taki model dla AI ktory nie ma mozliwosci prowadzenia przez uzytkownika, ale jesli jest inaczej to sie przyjrze.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 05 Marca 2017, 16:59:44
Cytuj
EU20 u mnie sie laduje, ale bez kabiny.

Bo jubaj wywalil. Kabina jest w paczce. MMd trzeba by dopasować i będziesz miał. ALe problemem tez sa 3e ze starsza kabina i 3e mod oraz zez. One tez się nie laduja a niebyly unoffami. Zobacz 3e-30.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: maciek001 w 05 Marca 2017, 17:02:13
Od exe eu07++170331 nie działa odbieranie informacji przez UART z zewnętrznego mikrokontrolera zrobione przez @maćka001 i dodane od exe eu07++170226, tzn. nie da się sterować nastawnikiem, hebelkami itd.
Nie mam pojęcia na razie ;) Na razie proponowałbym bazować na moich exe - tych nieoficjalnych. Może uda mi się do końca tygodnia poprawić sterowanie (w zasadzie to od początku zaczynam je robić) i dorzucić do głównego repo o ile nikt nie będzie miał zastrzeżeń.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 05 Marca 2017, 17:23:46
Ewidentnie coś jest skopane z tym nowym komunikatem - jak pisałem tamtego posta miałem w tle włączony symulator i wypluło mi w międzyczasie do errors.txt prawie całą litanię eventów, w tym eventy dżwiękowe czy sterujące semaforami z plików inc.
Przyjrzalem sie dokladniej, i wyszlo ze zrobilem bledne zalozenie co do tego, jak normalne robiony jest ten test, i w rezultacie procedura wylapywala takze eventy jak najbardziej "legalne". Teraz powinno byc ok:

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Sebol82 w 05 Marca 2017, 17:31:21
Czy jest opcja posprzątania trochę i wystawienia potrzebnych bibliotek w jednej paczce?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 05 Marca 2017, 17:38:10
Kompletna paczka bibliotek itp byla chyba zamieszczona niedawno w watku, sprawdz ostatnie 2-3 strony.

Testujac dalej, @EP, 3E-30 jak najbardziej laduje sie u mnie, lacznie z kabina, i jezdzi normalnie (nawet reczny jej dziala) To jest na 'czystej' paczce calosciowej + patch 16.08 i styczniowe (chyba) uaktualnienie. Jest jakas szansa, ze robiles jakies zmiany w swojej dystrybucji?

edit: ok, watek rusza sie szybko, to bylo wiecej niz 3 strony temu. @sebol, link do paczki calosciowej: http://eu07.pl/userfiles/24014/bugs-170303.rar
exe w srodku jest sprzed paru dni, wiec zlap najnowsze z tej strony, reszta plikow powinna byc w porzadku.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 05 Marca 2017, 17:52:19
Czy istnieje wpis blokujący zapis do pliku $.scn? W Rainsted trzeba to zaznaczać za każdym razem.
Aż nie wierzę. Krzysiu specjalnie dla ciebie.
Cytuj
Wersja/17.3.125
W pliku RAINSTED.INI, w sekcji [MASZYNA] można wpisać pozycję $.scn=0, której istnienie spowoduje brak załączonego ptaszka przy opcji Zapis pliku tymczasowego. Dla przywrócenia należy zmienić na $.scn=1.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 05 Marca 2017, 18:04:36
Antek, dzięki. Tak wyszło, że rozwoju rainsteda nie śledzę i przegapiłem to. Okazuje się, że część wywaleń exeka wyeliminowałem po wykluczeniu zapisu scenerii do $.scn. Niestety nie wszystkie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 05 Marca 2017, 18:20:38
Czy możecie mi swoje fizyki i mmd wystawić? na tych z patha ostatniego mi się model nie wyswietla.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 05 Marca 2017, 18:30:15
Czy możecie mi swoje fizyki i mmd wystawić? na tych z patha ostatniego mi się model nie wyswietla.

W mojej instalacji sa takie jak w zalaczniku.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 05 Marca 2017, 18:36:04
Ok, eventy działają już prawidłowo i nie sypie w logu dziwnymi wpisami. Z błędów na razie zauważyłem, że nie działa zakładanie / zdejmowanie sygnałów końca pociągu za pomocą SHIFT+T / T.

Mam też inny, intrygujący błąd. Mianowicie uruchomienie symulatora bardzo negatywnie wpływa u mnie na inne programy działające w tle. Przykładowo jeśli przeskoczę do Firefoxa ten się natychmiast wiesza, podobnie AIMP3 (odtwarzacz muzyczny) czy nawet MS Excel. Wiesza się też pasek zadań, a razem z nim możliwość przeskakiwania między programami, a naciśnięcie Shift+Alt+Delete daje efekt dopiero po parunastu minutach. Wtedy też system jakby się odblokowuje. Nie jest to problem z tą konkretną wersją exe, ale występuje już od dobrych kilku (kilkunastu) wersji. O co tu może chodzić?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 05 Marca 2017, 18:38:37
Nie mam pojecia, nie zauwazylem u siebie tego efektu. Czy takie zachowanie bylo tez w wersji 170228 i starszych, czy wystapilo od wersji 1703.. ?

edit: wlaczanie sygnalow koncowych faktycznie bylo uszkodzone, poprawka bedzie w nastepnym uaktualnieniu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 05 Marca 2017, 18:39:57
Kaliska 75FPS w Zduńskiej Woli. Exe 170305, załącznik. Okienka przełączam bez problemu, jadę dalej, między czasie zrobiłem screena i napisałem ten post na forum i dodałem załącznik.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Sebol82 w 05 Marca 2017, 18:49:51
Mam ten sam problem co @Siecool. Mianowicie kursor myszki działa mi tylko w obrębie okna z maszyną np. 800x600 mam win7 4gb ramu stery aktualne.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 05 Marca 2017, 18:54:25
U mnie wyglada to tak, ze po uruchomieniu symulatora kursor jest niejako 'przywiazany' do okna, natomiast po przelaczeniu aktywnego program Alt+Tab porusza sie normalnie po calym pulpicie, z tym ze w obszarze okna symulatora jest niewidoczny -- pojawia sie po przesunieciu myszy "poza" okno symulatora. Podobnie jest w trybie pelnoekranowym.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 05 Marca 2017, 19:11:27
Wszystko ładnie, ale posypały się eventy na kaliskiej, wygląda tak, jakby zwrotnice przestawiały się z dużym opóźnieniem. Zwrotki przestawiają się pod taborem. Odpalałem dwa razy, ten sam efekt.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 05 Marca 2017, 19:18:36
Czy to jest na 170305, czy 170305b ? W tym pierwszym faktycznie skopana byla obsluga eventow, dlatego wyszlo 170305b
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 05 Marca 2017, 19:25:58
Nie mam pojecia, nie zauwazylem u siebie tego efektu. Czy takie zachowanie bylo tez w wersji 170228 i starszych, czy wystapilo od wersji 1703.. ?

edit: wlaczanie sygnalow koncowych faktycznie bylo uszkodzone, poprawka bedzie w nastepnym uaktualnieniu.
Sprawdzę później, w międzczasie załatwiłem Ci dwa wysypy ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 05 Marca 2017, 19:32:23
Czy to jest na 170305, czy 170305b ? W tym pierwszym faktycznie skopana byla obsluga eventow, dlatego wyszlo 170305b
Na 170305, nie zauważyłem aktualizacji, próbowałem jeszcze raz i to samo.
Zabieram się za wersję b.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Waldi 1978 w 05 Marca 2017, 19:36:45
Witam.Pobrałem nowe exe + paczka bibliotek i problem z
Linia 61 osobowy od 1 do 3 zawiesza się na pierwszej sekundzie twania symulacji.Widok z kabiny i zawieszka.
Sprawdzałem na TD,Baltyku,Drawinowie nie ma tam takich zawieszek.

System Win XP.graf.Radeon X1950 XT.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 05 Marca 2017, 19:54:25
Sprawdz jesli mozesz czy w katalogu z symulatorem pojawily sie pliki o nazwie podobnej do exe, z rozszerzeniem .dmp? Jesli tak, to byloby swietnie gdybys je tu dal jako zalaczniki.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Waldi 1978 w 05 Marca 2017, 20:07:26
@tmj nie mam, wypluwa tylko errors text.
EDIT
Dodanie log text
@Krzysiek
Umknął mi przepraszam :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 05 Marca 2017, 20:19:46
Waldi, daj chociaż log.txt to też powinieneś mieć. 170305b, eventy na kaliskiej poprawne.
Trax w drawinowie też rusza spod W4. Exe nic mi nie wiesza, programy które odpalone są razem z symkiem to FF, okno czatu, paint, do tego notatnik i sporadycznie jakieś winrary lub ściąganie czegoś z netu. Tyle, że ja mam postawiony w tym tygodniu świeży system. Więcej dziś nie zrobię.
ED:
Potwierdzam wieszanie się na L061 osobowy 1 do 3. Ukazuje się kabina i dalej już nic nie można, nawet F10 nie działa, zamknąć trzeba na konsoli iksem, W załączniku log.
ED2: Waldi, mamy ten sam błąd.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 05 Marca 2017, 20:36:28
Sory, że post pod postem, ale nie chcę by umknęło. Zaremowałem wpis pliku include linia61/l61_auta.scm end na LO061. Sceneria wczytała się poprawnie, któryś z pojazdów jest trefny i raczej dziś już go nie namierzę. Choć nie twierdzę, że nie spróbuję.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 05 Marca 2017, 20:46:46
61 osobowy u mnie sie wczytuje, z tym ze plik na pewno nie jest calkiem zdrowy bo wyglada jak w zalaczniku, i produkuje garsc bledow "scene parse error". Ale na oficjalnym exe zachowanie i wyglad jest ten sam. Nie wiem czy to tak ma byc, czy jest skopane lokalnie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 05 Marca 2017, 21:12:28
W załączniku pojazdy które musiałem wywalić. Inaczej L061 się wiesza. Nie mam pojęcia czemu. Nie mam namieszane w pliku, screen mam poprawny.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 05 Marca 2017, 21:20:46
@tmj: ja się na tym nie znam co to robi, mógłbyś na to zerknąć?
Ground.cpp:InitNormals:193:
        for (i = 2; i < iNumVerts - 2; i += 2)
        {
            v4 = Vertices[i - 1].Point - Vertices[i].Point;
            v5 = Vertices[i].Point - Vertices[i + 1].Point;
            n3 = SafeNormalize(CrossProduct(v3, v4));
            n4 = SafeNormalize(CrossProduct(v5, v4));
            if (Vertices[i].Normal == vector3(0, 0, 0))
                Vertices[i].Normal = (n1 + n2 + n3) / 3;
            if (Vertices[i + 1].Normal == vector3(0, 0, 0))
                Vertices[i + 1].Normal = (n2 + n3 + n4) / 3;
            n1 = n3;
            n2 = n4;
            v3 = v5;
        }
        if (Vertices[i].Normal == vector3(0, 0, 0))
            Vertices[i].Normal = (n1 + n2) / 2;
        if (Vertices[i + 1].Normal == vector3(0, 0, 0))
            Vertices[i + 1].Normal = n2;
Jeżeli iNumVerts jest nieparzyste to Vertices[i + 1] jest juz poza tablicą. Mogę tam po prostu wlepić ifa ale nie chcę popsuć tych obliczeń.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 05 Marca 2017, 21:22:18
To exe jest jakies nienormalne. 2 razy na swiezej paczce uruchomiłem linie 53 scn tlk i raz kaliska. Kolejna proba uruchomienia tych samych scenerii skutkowało wywaleniem do windy. CHore. Robie sobie przerwe na 2 tyg od tego. Nie bede mial juz czasu na papranie sie z tym. Teraz w robocie bede mial wiecej pracy wiec i czasu na te papranine bedzie mniej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: loko w 05 Marca 2017, 21:31:02
Ja póki co sprawdziłem przejezdność misji EP09-005 ze scenerii Krzyżowa2 i jest przejezdna do końca na eu07++170305b.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 05 Marca 2017, 21:49:34
@tmj: ja się na tym nie znam co to robi, mógłbyś na to zerknąć?
(..)
Jeżeli iNumVerts jest nieparzyste to Vertices[i + 1] jest juz poza tablicą. Mogę tam po prostu wlepić ifa ale nie chcę popsuć tych obliczeń.
Z tego co widze, to tam sie licza wektory normalne, w tym przypadku dla triangle strip. Tutaj odwolania do wierzcholkow powinny byc chyba cofniete o 1, tzn
i - 1 powinno byc i - 2
i powinno byc i - 1
i + 1 powinno byc i

ale trzeba by to przetestowac, bo ten skok wartosci i o 2 jest dziwny, triangle strip tworzy kolejne trojkaty na podstawie jednego punktu + 2 poprzednie/startowe, a nie dwoch. Moze na poczatek daj zwykly assert i zobacz czy gdziekolwiek wyleci, bo moze byc tak, ze symulator uzywa triangle strip tylko do takich rzeczy jak drogi i tory, czyli praktycznie daje gwarancje, ze liczba wierzcholkow zawsze jest parzysta.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Mariusz1970 w 05 Marca 2017, 22:11:13
Jeśli chodzi o triangle_strip, taki includ stodoladrewn01detal.inc
//--------stodola
//param: tekstura_dachu x y z kat

origin (p2) (p3) (p4)

rotate 0 (p5) 0

// front

node 1000 0 none triangle_strip wood/WoodRedBrown2_agedPlanks
0 0 7 0 0 0 5 3 end
0 0 2 0 0 0 0 3 end
0 3 7 0 0 0 5 0 end
0 3 2 0 0 0 0 0
endtri

node 1000 0 none triangle_strip wood/WoodRedBrown1_Planks
0 0 2 0 0 0 4 3 end
0 0 -2 0 0 0 0 3 end
0 3 2 0 0 0 4 0 end
0 3 -2 0 0 0 0 0
endtri

node 1000 0 none triangle_strip wood/WoodRedBrown2_agedPlanks
0 0 -2 0 0 0 5 3 end
0 0 -7 0 0 0 0 3 end
0 3 -2 0 0 0 5 0 end
0 3 -7 0 0 0 0 0
endtri

// tyl

node 1000 0 none triangle_strip wood/WoodRedBrown2_agedPlanks
-6 0 -7 0 0 0 0 3 end
-6 0 7 0 0 0 10 3 end
-6 3 -7 0 0 0 0 0 end
-6 3 7 0 0 0 10 0
endtri

// sciany szczytowe

node 1000 0 none triangle_strip wood/WoodRedBrown2_agedPlanks
0 0 -7 0 0 0 0 0 end
-6 0 -7 0 0 0 6 0 end
0 3 -7 0 0 0 0 3 end
-6 3 -7 0 0 0 6 3 end
-3 6 -7 0 0 0 3 6
endtri

node 1000 0 none triangle_strip wood/WoodRedBrown2_agedPlanks
-6 0 7 0 0 0 6 0 end
0 0 7 0 0 0 0 0 end
-6 3 7 0 0 0 6 3 end
0 3 7 0 0 0 0 3 end
-3 6 7 0 0 0 3 6
endtri

// dach

node 1000 0 none triangle_strip (p1)
0.5 2.5 7.2 0 0 0 10 3 end
0.5 2.5 -7.2 0 0 0 0 3 end
-3 6 7.2 0 0 0 10 0 end
-3 6 -7.2 0 0 0 0 0
endtri

node 1000 0 none triangle_strip (p1)
-3 6 7.2 0 0 0 10 0 end
-3 6 -7.2 0 0 0 0 0 end
-6.5 2.5 7.2 0 0 0 10 3 end
-6.5 2.5 -7.2 0 0 0 0 3
endtri

// dach - podbitki

node 1000 0 none triangle_strip wood/WoodGrayBrown1_Planks
-3 6 7.2 0 0 0 3 0 end
-3 6 -7.2 0 0 0 0 0 end
0.5 2.5 7.2 0 0 0 3 1 end
0.5 2.5 -7.2 0 0 0 0 1
endtri

node 1000 0 none triangle_strip wood/WoodGrayBrown1_Planks
-6.5 2.5 7.2 0 0 0 3 1 end
-6.5 2.5 -7.2 0 0 0 0 1 end
-3 6 7.2 0 0 0 3 0 end
-3 6 -7.2 0 0 0 0 0
endtri

rotate 0 0 0

endorigin
i dziala (raczej :P )
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 05 Marca 2017, 22:39:51
no właśnie wylatuje, na bałtyku, na innych nie sprawdzałem. (co ciekawe tylko na buildzie x64)

dodałem ifa i wpis do loga, zmergowane to co tam tmj wrzucił na gita
https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng32-b65dd1a7.zip
https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng64-b65dd1a7.zip
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 05 Marca 2017, 23:36:25
Witam.
Nie wiem czy to celowe, ale na exe Tmj 170305b smuga oświetla również podczas symkowego dnia. Widać to dość dobrze podczas jazdy. Druga sprawa, mam odczucie jakby tekstury bardziej migotały niż na poprzednich wersjach.
Pozdrawiam
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 06 Marca 2017, 00:34:42
W załączniku pojazdy które musiałem wywalić. Inaczej L061 się wiesza. Nie mam pojęcia czemu. Nie mam namieszane w pliku, screen mam poprawny.
Odrestaurowalem linie 61 z paczki calosciowej + patch, i teraz laduje sie jak trzeba, a przy tym tez blokuje sie zaraz po starcie. Z tego co widze, to cos jest nie tak albo z ladowaniem/polaczeniem/skanowaniem niektorych drog, albo przeliczaniem ruchu. Na zalacznikach jest przyklad jednego z tych problematycznych samochodow, w exe c++ i oficjalnym: na samym starcie zanim cokolwiek jest liczone, drogi i polozenie pojazdow wyglada tak samo, ale po wylaczeniu pauzy w oficjalnym exe jelczostar jedzie normalnie do przodu, a w c++ teleportuje sie natychmiast na sam poczatek drogi, a  exe glupieje. Zeby bylo smieszniej w trybie debug wszytko chodzi jak trzeba, wiec albo cos tam jest nieinicjalizowane albo nadpisywane, trudno powiedziec.

edit: ciekawostka, wycialem ze sceny wszystko oprocz drog, torow i pojazdow, i wszystko jezdzi normalnie, bez dziwnych teleportacji. Czyli jakis inny element sceny sika tu exe do mleka.

edit2: ok, krasnoludkiem okazal sie wpis camera w jednym z plikow scenariusza. Zeby bylo smieszniej to nawet nie wiadomo czemu, bo na pobiezny rzut oka wszystko w kodzie definicji kamer bylo wpisywane gdzie trzeba, a nie gdzies na zewnatrz. Tak czy inaczej po zmianie tablicy na std::vector przestalo sie sypac.

Nie wiem czy to celowe, ale na exe Tmj 170305b smuga oświetla również podczas symkowego dnia.
W pewnym sensie, tzn sila swiatel pozostaje stala, natomiast efekt na otoczeniu zalezy od oswietlenia, jakie to otoczenie otrzymuje z innych zrodel (slonce + niebo) Na razie nie robilem tego dokladniej bo nie bylem pewien, jak to wyglada w naturze, ale patrzac na youtube to w ciagu dnia efekt jest praktycznie zaden, wiec to jest to poprawienia.

Sprawdzę później, w międzczasie załatwiłem Ci dwa wysypy ;)
Pamietasz moze, w jakich okolicznosciach to sie stalo? Tzn na jakiej trasie, i czy od razu, czy kiedy robiles moze cos specyficznego. Moze sa jakies wpisy w errors.txt (oprocz tradycyjnych o braku tekstur i takich tam ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 06 Marca 2017, 07:57:08
To exe jest jakies nienormalne. 2 razy na swiezej paczce uruchomiłem linie 53 scn tlk i raz kaliska. Kolejna proba uruchomienia tych samych scenerii skutkowało wywaleniem do windy. CHore. Robie sobie przerwe na 2 tyg od tego. Nie bede mial juz czasu na papranie sie z tym. Teraz w robocie bede mial wiecej pracy wiec i czasu na te papranine bedzie mniej.
Włodku, czego Ty się spodziewasz? Nie ma tak, że ktoś przepisze i będzie działać. To nie jest dyktando, gdzie do wyłapania błędów wystarczy przeczytać. Dziennie odpalam kilkadziesiąt razy exe z jakąś scenerią, w przypadku L61 osobowy odpaliłem ponad 40 razy w ciągu 90 minut, eliminując po kolei trefne wpisy. W tym wątku pracujemy na stabilność exe i jego jak najlepsze wyniki. Jeszcze o Kaliskiej napiszę, że na niej masz wysypy odkąd jest ta sceneria, nawet na exe z paczki, o tym pisałeś wielokrotnie. Odpocznij i przemyśl co w tym wątku robimy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: art72 w 06 Marca 2017, 16:30:11
Krzysiek ma w 100% rację - nie ma powodów do "fochania".

Usuwanie bugów z aplikacji to mrówcza praca ale cieszy fakt, że topik cieszy się sporym zainteresowaniem. I co więcej, @tmj w ramach koleżeńskiej współpracy natychmiast modyfikuje kod programu.

Cenna inicjatywa tym bardziej, że na ogół informatycy, którzy umieją zrobić coś konkretnego albo liczą sobie krocie za świadczone przez siebie usługi albo trudno się z nimi rozmawia. Bo żyją w swoim, wypełnionym elektronicznymi rozkazami, świecie ;)

[EDYTA]

Nadal mam 60fps bez wpisów do ini. Synchronizacja monitora włączona. Czemu mam tak wysoki fps? Skąd taka różnica u mnie i u @art?

Krzysiu, różnice w ilości wyświetlanych klatek/sekundę mogą być pochodną małej ilości posiadanego przeze mnie RAMu: tylko 2GB.

Na XP-ku wystarczała do wszystkiego, na siódemce przydałoby się co najmniej drugie tyle.
(swoja drogą - to jakaś chora polityka, żeby "goły" system "zjadał" blisko połowę zasobów sprzętowych)

Ale nie chcę już inwestować w mojego blaszanego złoma - kości DDR2 produkcji Kingstona pewnie będą kosztowały majątek.
(no i, jak powszechnie wiadomo, kupno nowych RAM-ów ma niski WAF czyli Wife Acceptance Factor :D)

W dodatku mam 32-bitowy system, dlatego możliwość ewentualnego rozszerzenia pamięci jest mocno ograniczona.

PS. z imieniem oczywiście dobrze trafiłeś ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 06 Marca 2017, 17:15:56
Pamietasz moze, w jakich okolicznosciach to sie stalo? Tzn na jakiej trasie, i czy od razu, czy kiedy robiles moze cos specyficznego. Moze sa jakies wpisy w errors.txt (oprocz tradycyjnych o braku tekstur i takich tam ;)
Wszystkie wysypy na tej samej scenerii i misji, niestety jeszcze nieopublikowanej, ale jak będziesz chciał to mogę podrzucić. Co do czasu to pierwszy wysyp nastąpił chyba po 2h jazdy, drugi natomiast po 8 minutach. Generalnie jest to ta sama sceneria i misja, co pisałeś o błędzie z RList tylko nie wiem niestety, jakiego pojazdu to się tyczy. Errors pokazuje to co zwykle - brak passengers.t3d w wagonach plus dwa razy brak animations tag - w st44, którym jechałem i wagonach 203vb (Flls). Te dwa wysypy też wyleciały na sczytywaniu RList czy coś innego?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 06 Marca 2017, 17:24:16
Dałem Milkowi devsa, więc obaj nasi programiści maja dostęp do scenerii już. :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 06 Marca 2017, 17:41:08
Te dwa wysypy też wyleciały na sczytywaniu RList czy coś innego?
Tak, w tym samym miejscu co poprzednio. Problem w tym, ze nie ma gwarancji ze wylatuje akurat na tej linii, dlatego chcialbym jesli mozliwe wywolac ten blad u siebie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 06 Marca 2017, 18:01:41
Zajrzyj tutaj: http://eu07.pl/forum/index.php/topic,26934.msg444039.html#msg444039
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 06 Marca 2017, 18:32:57
@Milek7, katowałem twoje exe, i jak dotąd nie udało mi się wywalić je do windy. Męczyłem wersję 32 bitową na nowo postawionym win xp. Nawet raz odpaliłem dwa razy, jednocześnie załadowałem Drawinowo i L053. Jeśli wyłączyć zapis do plik $.scn, to rainsted uruchomi aplikację drugi a nawet trzeci raz. Mimo 100% mocy wykorzystania procka i gorącej grafiki oba scenariusze ukończyłem.
@tmj, oprócz L61 osobowy, wszystkie scn załadowały się bez problemu. Jednak, trzeba by sprawdzić czy okresowe wysypy u mnie na Quarku, również nie są powodowane przez wpisy samochodów. Rano wszystkie usunąłem i wysypy ustąpiły.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 06 Marca 2017, 19:02:31
@Milek7, jest gdzies do sciagniecia skompilowany .lib itp dla libpng, czy trzeba je sobie recznie skladac? ;/
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 06 Marca 2017, 19:04:55
ręcznie. dołączyłem mój, ale robiony na vs2015 więc nie wiem czy kompatybilny
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 06 Marca 2017, 19:28:32
Bleh. Dzieki, sprawdze pozniej. BTW, sizeof(TSubModel) przy kompilacji VS2013 to 300 bajtow, nie 256 (308 w trybie debug) ale po usunieciu testu wyglada na to ze dziala ok, przynajmniej jesli chodzi o ladowanie .e3d  Byc moze kwestia ustawien kompilacji, nie wiem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 06 Marca 2017, 19:36:32
mówisz o moim kodzie? tam jest zrobiona serializacja każdego pola osobno, więc wielkość nie ma znaczenia.
a jeżeli chodzi o oryginalny to raczej się posypie, bo wczytywanie/zapisywanie do pliku to bezpośrednie kopiowanie pamięci.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 06 Marca 2017, 19:56:14
mówisz o moim kodzie?
W World::Init jest taki kawalek na poczatku
if( sizeof( TSubModel ) != 256 ) {
Error( "Wrong sizeof(TSubModel) is " + std::to_string(sizeof( TSubModel )) );
return false;
}
i po polaczeniu symulator of razu sie na tym zamykal, bo wielkosc objektu jest teraz inna. Myslalem, ze to cos od ciebie, ale jak teraz sprawdzam to jest w kodzie od dawna, i po zmianach sie aktywowal, ale wyglada na to ze na 2015 sie nie czepia, jesli przeszedl niezauwazony :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 06 Marca 2017, 20:00:28
obecnie tego checka u mnie nie ma. jak mergujesz to musisz raczej z najnowszym, bo commity mogły być niepełne lub mieć krytyczne bugi naprawione dopiero w późniejszych.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 06 Marca 2017, 20:27:17
Hmm dalem mu fetch/pull tuz przed merge, wiec powinno byc najnowsze, w history pokazuje ze to stan na 22:34 z wczoraj. Nie wiem czemu tego kawalka nie wylapal, zrobie pozniej compare.

Tak czy inaczej, dzisiejsze uaktualnienie w zalaczniku. Ma teraz (teoretycznie) wszystkie zmiany od Milka, minus zgrywanie zrzutow ekranu, bo wyglada na to ze lib z 2015 mu nie pasuje, bede musial zrobic swoj. Dodatkowo poprawki z wczoraj:
- przywrocona obsluga uruchamiania eventow z klawiatury
- poprawka obslugi definiowanych kamer, nie powinno wiecej wieszac sie na l61_osobowy
- przywrocone umieszczanie sygnalow koncowych
- reflektory lokomotyw w ciagu dnia maja znikomy (czytaj zerowy) efekt
- moze cos tam jeszcze, czego nie pamietam

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 06 Marca 2017, 20:42:19
L61, nie wiesza symulacji. Co prawda trzeba by przejechać całą scenerię chociaż raz, aby być pewnym. Lamp nie widać, w porównaniu z wczorajszym, gdzie był odblask na słupach sieci.
Coraz bardziej niebiesko jest?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: dymus w 06 Marca 2017, 21:20:20
Pusta sceneria, brak zdefiniowanych eventów i shift+3 wywołuje efekt jak Radiostop (spadek ciśnienia w przewodzie), to samo na np. Bałtyku i pewnie na innych sceneriach.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 06 Marca 2017, 21:21:53
Potwierdzam, uruchomienie radiostopu na TD.scn
ED:
Brak terenu w Drawinowie, załącznik. Drawinowo: shift+3 hamowanie opróżnienie PG, ale brak ciśnienia w cylindrach hamulcowych EP09.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 06 Marca 2017, 21:32:16
Tak, zaplatalo sie pod klawisz 3, powinno byc ctrl+pause. Bedzie poprawione w nastepnej wersji.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 06 Marca 2017, 21:33:48
W misji l61_osobowy2 taki oto błąd:
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 06 Marca 2017, 21:38:49
@pbzylek, masz to samo co ja w Drawinowie. Sreen w poprzednim poście. Na poprzednim exe mam ok.
To hamowanie awaryjne było już na 170305b
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 06 Marca 2017, 21:40:33
Ja również na poprzednim exe poprawnie miałem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 06 Marca 2017, 22:17:02
Mozna dostac jakiejs wspolrzedne gdzie te dziury sa, spod F2? Bo dralowac przez cala scenerie to troche nieciekawy prospect jest :d

Drawinowo ma u mnie dziure w okolicy tuneli (i mialo od dawna, wiec to nie wina ostatniej modyfikacji) ale akurat ta stacja wyglada normalnie :/

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 06 Marca 2017, 22:22:41
Drawinowo, u mnie to tak jakby w zasiegu wzroku bylo w okol stacji. Dalej nie zapuscilem sie. L061 sprawdzalem tylko wysyp na tyc kamerach, tez nie zpuszczalem sie w glab. Przejechalem calego Quarku, tu ciemnosc, ale nic nie rzucilo sie w oczy. Zerknalem tez na manewrowo, tam jest ok. Na dzis to tyle, mam inne zajecia w domu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 06 Marca 2017, 22:25:45
Zarówno Drawinowo jak i l61 (wersja Ra) mają teren wczytywany z e3d. Tu bym szukał przyczyny. Ze dwa dni temu wczytywało go poprawnie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 06 Marca 2017, 22:28:45
Drawinowo, u mnie to tak jakby w zasiegu wzroku bylo w okol stacji. Dalej nie zapuscilem sie. L061 sprawdzalem tylko wysyp na tyc kamerach, tez nie zpuszczalem sie w glab. Przejechalem calego Quarku, tu ciemnosc, ale nic nie rzucilo sie w oczy. Zerknalem tez na manewrowo, tam jest ok. Na dzis to tyle, mam inne zajecia w domu.
A na moim exe w drawinowie nie było dziur? Bo oprócz tych screenshotów to praktycznie żadnych znaczących różnic nie powinno być teraz między moimi exekami a tmj.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 06 Marca 2017, 23:14:33
Witam.
 Z tym błędem przy wczytywaniu terenu to loteria jest. Wczoraj na L61 miałem brak terenu, dzisiaj wczytał się poprawnie. To samo exe Tmj 170305b, ta sama misja. Sprawdziłem też opisywany problem ze służbą osobowy 1-3. Uruchomiłem dwójkę, i co ciekawe sceneria została wczytana normalnie. Errors wygenerował co prawda jakieś błędy, ale nic poza tym. Czy to może od komputera zależy sam nie wiem. Byłbym zapomniał, korzystam z Lini61 w wykonaniu Ra.
Pozdrawiam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 06 Marca 2017, 23:34:54
A na moim exe w drawinowie nie było dziur? Bo oprócz tych screenshotów to praktycznie żadnych znaczących różnic nie powinno być teraz między moimi exekami a tmj.
Cos w przepisanym ladowaniu jest zakrzaczone raczej na pewno -- dla przykladu, ta beta calkowo v2 ktora robi Siecool wgrywa sie z pustym terenem, natomiast na starej kompilacji teren pojawia sie poprawnie. Blad jest zarowno na twoim exe jak i ostatnim moim, wiec to raczej nie kwestia ze cos selektywnie skopalo sie przy portowaniu.

dla ulatwienia debugowania, mozesz w pliku calkowo_v2_zdawczyB_pom.scn zakomentowac /* */ wszystko ponizej linii
node -1 -1 none model 0 0 0 0 slimson/calkowo_v2/calkowo_v2_teren.t3d none endmodel
W ten sposob bedzie ladowalo tylko obiekt terenu, ktory sie nie wyswietla.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 07 Marca 2017, 08:12:08
ok, sprawdzę po południu
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 07 Marca 2017, 09:29:32
Znowu mi wrócił błąd float to GLUint. Gdzie w opcjach się wywala ten error?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 07 Marca 2017, 10:05:10
Drawinowo, u mnie to tak jakby w zasiegu wzroku bylo w okol stacji. Dalej nie zapuscilem sie. L061 sprawdzalem tylko wysyp na tyc kamerach, tez nie zpuszczalem sie w glab. Przejechalem calego Quarku, tu ciemnosc, ale nic nie rzucilo sie w oczy. Zerknalem tez na manewrowo, tam jest ok. Na dzis to tyle, mam inne zajecia w domu.
A na moim exe w drawinowie nie było dziur? Bo oprócz tych screenshotów to praktycznie żadnych znaczących różnic nie powinno być teraz między moimi exekami a tmj.
Niestety też, załącznik. U mnie za każdym razem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 07 Marca 2017, 10:21:03
Witam.
 Z tym błędem przy wczytywaniu terenu to loteria jest. Wczoraj na L61 miałem brak terenu, dzisiaj wczytał się poprawnie. To samo exe Tmj 170305b, ta sama misja. Sprawdziłem też opisywany problem ze służbą osobowy 1-3. Uruchomiłem dwójkę, i co ciekawe sceneria została wczytana normalnie. Errors wygenerował co prawda jakieś błędy, ale nic poza tym. Czy to może od komputera zależy sam nie wiem. Byłbym zapomniał, korzystam z Lini61 w wykonaniu Ra.
Pozdrawiam.
Nie potwierdzam że to loteria, mam za każdym razem na exe od @tmj 170306 i ostatnim @milka7 (32bitowym), natomiast na 170305B mam zawsze poprawnie, załącznik 2.
Nie uruchamiam L061 od @Ra, tylko to z paczki całościowej. Jak pisałem w innym wątku, Drawinowo od @Ra jest w trakcie zmian, więc nie wiadomo czy tam się coś dodatkowo nie sypie. A szukać czy to sceneria, czy exe jest winne, nie chce mi się. Sprawdzam na sceneriach, których zachowanie potrafię przewidzieć.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 07 Marca 2017, 10:43:59
ok, nie trzeba już testować.
później zobaczę co się tam zepsuło
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 07 Marca 2017, 14:01:32
Na probe cofnalem pliki model3d do wersji poprzedniej i teren wrocil do normy, ale podejrzewam, ze problem moze byc nie w samym ladowaniu, a np w funkcjach ktore obrabiaja plik terenu -- jesli tam sa jakies sztywne zalozenia co do struktury, offsetow itp, to po zmianach cos tam sie moze rozjezdzac.

edit: znalazlo sie. Przy konwersji zgubiles ten kawalek w BinInit():
        if( Opacity < 1.0 ) // przezroczystość z tekstury brana tylko dla Opacity 0!
            iFlags |= GfxRenderer.Texture( TextureID ).has_alpha ?
            0x20 :
            0x10; // 0x10-nieprzezroczysta, 0x20-przezroczysta
        else
            iFlags |= 0x10; // normalnie nieprzezroczyste
w rezultacie teren nie mial ustawionych flag widocznosci. Po dopisaniu z powrotem wyswietla sie normalnie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 07 Marca 2017, 15:02:32
Hamowanie pod shft+3 usunąłeś?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 07 Marca 2017, 15:02:59
już wywęszyłem że to problem z flagami, ale ubiegłeś mnie :)

tak też jest źle, zobacz że pewnie zepsułeś np. czuwaka w EP08-006 (otwierane z E3D)
Pole Opacity nie istnieje w E3D i nie jest z niego ładowane. (poprzednio było, ale raczej przez przypadek, bo było w "zmiennych roboczych" i nie jest opisane na stronie rainsteda). Prawidłowe flagi przeźroczystości ustawiają się w iFlags przy ładowaniu pojazdów z T3D i zapisywane już są dobrze w E3D, pewnie brakuje tego w terenie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 07 Marca 2017, 15:04:25
To jak determinowana jest faza renderowania w której dany obiekt ma być wyświetlony?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 07 Marca 2017, 15:06:36
Jest w iFlags. Znaczy powinno być, w pojazdach jest, ale w terenie tego najwyraźniej brakuje. (trzeba by to dopisać do ładowania terenu z pliku i wygenerować jeszcze raz e3d terenu)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 07 Marca 2017, 15:46:17
Hamowanie pod shft+3 usunąłeś?
Tak, powinno byc teraz pod ctrl + pause.

tak też jest źle, zobacz że pewnie zepsułeś np. czuwaka w EP08-006 (otwierane z E3D)
Faktycznie, ale to akurat proste do poprawienia -- albo daj domyslna wartosc Opacity na 0.0f (w SubModel::FirstInit albo konstruktorze) co wymusi test tekstury, albo mozemy wymusic test bezposrednio, redukujac ten kawalek do
            iFlags |=
                ( GfxRenderer.Texture( TextureID ).has_alpha ?
                    0x20 :
                    0x10 ); // 0x10-nieprzezroczysta, 0x20-przezroczysta
bez warunkow if( Opacity ...) itd. Sprawdzilem na szybko i dziala, bedzie w nastepnym uaktualnieniu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 07 Marca 2017, 16:06:22
Może być. W takiej sytuacji można też pewnie wywalić tego ifa z Model3d.cpp:379. (żeby było tak samo jak w ładowaniu E3D, zresztą renderowanie jako nieprzeźroczyste mimo że tekstura ma alfę jest raczej bez sensu)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 07 Marca 2017, 16:11:43
Hmm pewnie tak, chocby dla ujednolicenia. Chociaz docelowo chcialbym, zeby byla mozliwosc rozroznienia miedzy tekstura z alfa ktora powinna byc blendowana, tekstura z alfa ktora powinna byc uzyta przy alpha_test, i tekstury z alfa, gfzie A jest uzywane przy multitexturing. Ale to bym raczej umiescil w 'texture traits' czyli jako parameter podawany razem z nazwa tekstury, tak jak kontrola zawijania itp.

(a juz calkiem docelowo, to powinna o tym decydowac definicja zastosowanego materialu, ale to juz inna bajka)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 07 Marca 2017, 16:21:00
Drawinowo i wyświetlanie terenu, jest OK. Hamowania awaryjne tam gdzie trzeba. Są inne problemy. Po podświetleniu przyrządów shift+; mamy przezroczystość na haslerze i dziwne cienie na manometrach i miernikach (tam gdzie jest podświetlane), załączniki. Najgorsze jest to, że po odpaleniu tym exe TD i Drawinowa, nie mogę odpalić ich starszymi exekami.

Sprawdź to proszę, bo może uszkadza jakieś pliki modyfikując je dla siebie. To na ten moment pilne jest, jakby co to trzeba zdjąć exe z załącznika bo szkodzi.

ED:
W załączniku dodaję log, gdzie niemożliwe jest otwarcie scenerii starszym plikiem. Zatrzymuje się w tym samym miejscu i stoi.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 07 Marca 2017, 16:28:11
Przeźroczystość to to samo co kiedyś zgłaszałeś z czuwakiem. (a ja "naprawiłem" i zepsułem teren :P).
Już uzgodniliśmy naprawę z tmj.

Możliwe że nowe E3D nie działają na starym exe (pewnie dlatego że już po uruchomieniu konstruktora ładuje z pliku strukturę submodelu, a w nowym e3d puste miejsce jest wypełnione zerami, a wcześniej wpychała się tam reszta obiektu), ale jak już są wygenerowane to nie powinny się nadpisywać.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 07 Marca 2017, 16:32:39
Zajmie mi nieco przekopiowanie pewnego katalogu dynamic. Sprawdzę jeszcze raz czy odpalę na starym exe z paczki, starszym C++ i dzisiejszym. Jeśli ponownie popsuje się wczytywanie na starszym exe, to tak nie może zostać. Nie każdy poradzi sobie z naprawą paczki, a testy są w otwartym dziale.
Jeśli tworzenie nowych e3d psuje możliwość użycia starszych exeków, to trzeba rozwiązać ten problem, lub przenieść testy do zamkniętego działu i ostrzegać przed taką możliwością. To zresztą chyba ostateczność.
ED:
Błąd poprzedniej przezroczystości dotyczył lampek SHP, tu jest w haslerze. Tym razem shp wyświetla się dobrze nawet podświetlone.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 07 Marca 2017, 16:40:22
Na szybko mozna zapewne tego uniknac przez ustawienie convertmodels 0 w .ini, tak zeby exe nie generowalo zadnych nowych .e3d Wczytywanie bedzie troche wolniejsze, ale nic nie zepsuje. Tymczasowo ustawie to na sztywno, zeby nie psulo ludziom, ktorzy nie beda wiedziec ze trzeba cos wpisac.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 07 Marca 2017, 16:48:27
To i tak występuje tylko na paczce T3D/TGA, a żeby wrócić do starego exe wystarczy skasować wszystkie pliki .e3d. Wyłączenie tego na sztywno pozbawi jakichkolwiek testów kodu nowego zapisywania e3d.
No ale jeżeli jest to jakiś większy problem to mogę spróbować wcisnąć tam te struktury żeby było kompatybilne ze starym exe.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 07 Marca 2017, 16:50:40
Tak, tylko paczka na której pracuje to dds z e3d. Nie mam t3d, więc tylko kopiowanie zostaje. Paczka z t3d jest paczką developerską, nie dla końcowego użytkownika. Nie wiem też, czemu exe wczytuje scenerie z e3d i potem zapisuje nowe e3d. Zresztą dokładnie sprawdzę, ja to jest, bo na ten moment nie złapałem tego za rękę.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 07 Marca 2017, 16:52:53
Jak to? E3D powinny zapisywać się tylko przy ładowaniu z T3D. Pokaż loga.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 07 Marca 2017, 17:15:32
Sprawdzajac na szybko, zapisuje u mnie tylko .t3d, natomiast .t3d to czesto miedzy innymi chmury itp (rowniez w paczce dds) wiec faktycznie latwo moga popsuc dane dla starego exe.

W ramach kompromisu, uaktualnienie:

- naprawione wyswietlanie opacity
- convertmodels jest domyslnie wylaczone, a wlaczenie wymaga wpisania w .ini convertmodels z parametrem o 128 wiekszym niz do tej pory. tzn jesli wczesniej dzialalo convertmodels 7, to teraz trzeba wpisac 135. Tym sposobem ciagle mozna testowac zapis, ale niepoinformowanym uzytkownikom nie powinno zaszkodzic.

edit: slepy jestem i dalem nie ten build, sorry :d teraz powinien byc dzisiejszy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 07 Marca 2017, 17:16:32
Tego pierwszego loga z odpalenia 170307 nie mam... Dałem wcześniej ten z td, nieudany...
Narobiłem zamieszania za co przepraszam, ale chyba sprawa istotna, z obawy by komuś w paczce nie namieszać. Jest ok, na scenerii wstawione były modele t3d i dotąd nie robiły zamieszania. Po ich zaremowaniu jest dobrze.
W załączniku poprawnie świecące manometry.
ED:
Super, jak ktoś ma modele z t3d to się nie złapie na tym. Zastanawia mnie na ile błędy u @EP08-15 mają taką genezę. Oczywiście nie wszystkie.

ED1:
Wyświetlanie podświetlonych wskaźników jest w porządku. Teren w drawinowie jest i idę wałkować inne scenerie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: dymus w 07 Marca 2017, 18:46:22
Chyba tego nie było zgłaszane ale:
eu07++170307b
•częstotliwosc migania czuwaka jest zbyt mała (mniej więcej dwa razy wolniej niż poprzednie exe)
•na przyśpieszeniu (np. ctrl+f6) czas ewentualnego zadziałania nadmiarowego przetwornicy jest taki sam jak na bez przyśpieszenia (tak jakby nie uzględniało przyśpieszenia czasu, wcześniej było ok, teraz - chyba od 2 wersji exe - to się pojawiło). tak samo czas załączenia wyłączyka szybkiego też jakby nie uzględniała przyśpieszenie czasu, poprzednie exe na przyśpieszeniu szybki załącza się od razu, tutaj na przyśpieszeniu czas jest dośc porównywalny do tego bez przyśpieszenia. to samo częstotliwość migania czuwaka na przyśpieszeniu, oraz czas po którym po naciśnięciu przycisku czuwaka zaczną migać lampki
•zwiększył się czas załączenia wyłącznika szybkiego (bez zmian w plikach fiz czy coś) (1.25 teraz, 0.75 sekundy - mniej więcej - na tym samym pojeździe, krótszy czas na exe 170303)  na innym pojeździe teraz 1.20, wcześniej 0.75 na exe 170303) więc wygląda na ogólnie dwukrotne wydłużenie czasu
•kran hamulca zaspolonego porusza się mniej więcej dwa razy wolniej (chodzi o poruszanie się klawiszami 3 i 9)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 07 Marca 2017, 19:04:36
To jak w końcu jest z e3d? +128 do flagi to rozwiązanie przejściowe? Nie straszcie potrzebą rekompilacji wszystkich modeli binarnych.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 07 Marca 2017, 19:05:30
stare działają, tylko e3d wygenerowane na nowym nie otwierają się na starym exe
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 07 Marca 2017, 19:21:32
Nie było zgłaszane, co prawda długie załączenie szybkiego za plus.
Nadal nie działa pauza, była pod Pause/break. Migotanie na styku przenikających się tekstur, dokładnie i najlepiej wkurza przy przenikaniu tekstury podsypki i trawy, to zawsze było, teraz jakby więcej. To jednak może niech ktoś jeszcze zerknie, taka ocena przecież może być subiektywna z powodu zbyt długiego ślęczenia przed komputerem.
Nie wiem czy to na później, ale jest problem z latarniami. Pierwszy obrazek, to przejazd, na którym są latarnie, z bliska mało tego światła, ale ono z natury takie było. Drugi obrazek, to widok na te same latarnie z daleka, mimo niewidocznej latarni i tego co tam jest w okół, światłość jest niewspółmiernie duża. Obawiam, się jednak, że jest to ruszenie całej struktury freespotów, łącznie z semaforami, światłami końca pociągu i tym podobne.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 07 Marca 2017, 19:38:04
Nadal nie działa pauza, była pod Pause/break.
Pauza jest pod Esc, ale nie jest zalaczana w trybie debug i/lub aktywowanej opcji multiplayer w .ini  Tak samo jest chyba w oryginalnym exe. Sprawdzilem na szybko, i w trybie normalnym u mnie dziala, notyfikacja "paused" pojawia sie kolo zegara, a zegar symulacji (i sama symulacja) staje do czasu ponownego nacisniecia Esc.

Problem z latarniami jest ten sam co z punktowymi swiatlami lokomotyw, itp -- na duzy dystans wlaczane jest rysowanie 'punktow' zamiast tekstury swiatel, ktore sa wieksze, i tym samym wyrazniejsze niz "falszywe" tekstury swiatel. Nie mam na razie konkretnych pomyslow co tam zmienic.

@dymus, czy mozesz porownac takze czestotliwosci migotania, predkosci itp z oryginalnym exe? Nie pamietam na 100% czy w 02-03 i pozniej byly jakies zmiany w tym temacie, ale porownujac "okno w okno" dzisiejsza wersje z exe Borlanda predkosci wydaja sie identyczne -- np hamulec zespolony po przytrzymaniu klawisza 3 przechodzi z polozenia 'polnoc' do 'poludnie' w ~4 sekundy, czuwak na oko miga z identyczna predkoscia, itp. Przy jakim FPS bylo to zauwazone, 60 czy mniej?

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 07 Marca 2017, 20:15:45
Jakiś programik wyłąpujący obiekty typu freespot w t3d i zmniejszajacy mindist dla zadanego progu potrzeba. Notatnikiem tego nie ogarnę. Większa kropa będzie się pojawiać wcześniej i powinno być dobrze.
Większość latarni nie ma freespota tylko "gwiazdkę" (stars, jak czasza nieba). Skoro one też są większe, to nie szkodzi to wyglądowi gwiazd na niebie?
W borlandzie była paza pod klawiszem Pause działająca w obu trybach. Pauzowanie w debugmode też jest potrzebne.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 07 Marca 2017, 20:27:10
Podczas renderowania nieba wielkosc punktow jest zmniejszana, inaczej faktycznie gwiazdy bylyby zbyt duze :)  Zmniejszenie mindist dla freespotow mozna zapewne wpisac do exe, zobacze jak to wyjdzie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 07 Marca 2017, 20:32:52
Lepiej osobny programik, co by było selektywne. Czasami może być potrzeba innych ustawień.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 07 Marca 2017, 20:44:54
Znalazlem jeden z bledow wysypow u siebie. Może się komus przyda na przyszlosc. Exe wywalalo się na uszkodzonym pliku gray.dds z folderu db/rlmmp.
Zalaczam owy uszkodzony plik. Stare exe to omijalo i po prostu pojazd był bialy. Podobny blad mam na pierwszej wersji wagonu bmz. Program iview także tych plikow nie może otworzyć. Wlasciwe dds iview otwiera (z wtyczka oczywiście) a exe je wczytuje bez kłopotu. Warto by na to spojzec. Lepiej niech wywali blad ze plik niemożliwy do wczytania, ale niech pozostawi pojazd bialy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 07 Marca 2017, 20:47:02
Skąd on jest? Trzeba go otagować do ponownej konwersji przy składaniu paczki.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: dymus w 07 Marca 2017, 21:02:40
Cytuj
@dymus, czy mozesz porownac takze czestotliwosci migotania, predkosci itp z oryginalnym exe? Nie pamietam na 100% czy w 02-03 i pozniej byly jakies zmiany w tym temacie, ale porownujac "okno w okno" dzisiejsza wersje z exe Borlanda predkosci wydaja sie identyczne -- np hamulec zespolony po przytrzymaniu klawisza 3 przechodzi z polozenia 'polnoc' do 'poludnie' w ~4 sekundy, czuwak na oko miga z identyczna predkoscia, itp. Przy jakim FPS bylo to zauwazone, 60 czy mniej?
Scn testowa (sam tor, więc mniej niż TD :P).
exe474 (jakieś tam starsze z paczki): 20mignięć czuwaka  w 7 sekund,  FPS 60, przejście od jazdy do nagłego przy klawiszu 3: 3.3sek  czuwak co 60sek (pomiędzy załączeniami podczas jazdy, jest ok).
exe++170302: 20 mignięć ~7-8sekund, FPS 170,  przejście od jazdy do nagłego przy klawiszu 3: 3.3sek, czuwak co 60sek
exe++170303: 20 mignięć ~7-8 sekundy, FPS 61 (mam zablokowane przez "vsync yes" bo coś mi się laptop przy więcej grzał, bo miał 150+ FPS), przejście jazda nagłe ok. 3 sekundy, czuwak co 60sekund
exe++170307b: 20 mignięć w 11.4sek, FPS 61 (vsync yes), przejście jazda na nagły 6sek, czuwak co 60sek
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 07 Marca 2017, 21:18:45
Ktoś zerknie na drezynę WM15? Potwierdzam, że na Zwierzyńcu transport, dostaje małpiego rozumu. Przejechałem Kaliską od Ostrowa do Łodzi. Nie miałem żadnych problemów.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 07 Marca 2017, 21:18:59
Cytuj
Skąd on jest? Trzeba go otagować do ponownej konwersji przy składaniu paczki.

dynamic/db/rlmmp_v1
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 07 Marca 2017, 21:35:17
Coś jest wyraźnie nie tak z ucinaniem obiektów z boku kamery. Oprócz tych trójkątów jeziora, pojazdy też znikają. FPS=46, 1080p 16:9, ustawiłem kamerę by mi skład wjeżdżał z rogu monitora. Wagony renderowały się dopiero gdy były już ze trzy metry na ekranie. Wcześniej środek dynamica musiał być przynajmniej z pół km za kamerą by ten się nie wyświetlał.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 07 Marca 2017, 21:38:50
Antek, to jak już to popatrz na składy z góry, tak abyś obejmował około 10-15 wagonów. Patrz pod różnym kątem w stosunku do osi toru na skład, ja nie umiem tego nazwać. Bywa, że coś znika.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 07 Marca 2017, 21:40:31
Znalazlem jeden z bledow wysypow u siebie. Może się komus przyda na przyszlosc. Exe wywalalo się na uszkodzonym pliku gray.dds z folderu db/rlmmp.
Zalaczam owy uszkodzony plik. Stare exe to omijalo i po prostu pojazd był bialy. Podobny blad mam na pierwszej wersji wagonu bmz. Program iview także tych plikow nie może otworzyć. Wlasciwe dds iview otwiera (z wtyczka oczywiście) a exe je wczytuje bez kłopotu. Warto by na to spojzec. Lepiej niech wywali blad ze plik niemożliwy do wczytania, ale niech pozostawi pojazd bialy.
Zgadza sie, ten gray.dds wyskoczyl wczesniej i wygenerowalem wtedy poprawiona wersje z .tga, ale przysiaglbym ze dalem tez poprawke zeby sie na tym nie wysypal, a wychodzi na to ze zapomnialem. Dopisze na przyszlosc poki jeszcze (znowu) pamietam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 07 Marca 2017, 21:47:54
Owszem, dawałeś w tym poście: http://eu07.pl/forum/index.php/topic,28159.msg442512.html#msg442512
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: EP08_015 w 07 Marca 2017, 21:53:18
Nie da się tego zrobić, by w podobnych przypadkach exe to olewalo? Oczywiście info do errors mile widziane i w logu tez.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 07 Marca 2017, 22:11:48
No mowie, ze wczesniej zapomnialem, a teraz bedzie, od jutra. I olewac, i krzyczec ;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 07 Marca 2017, 22:25:59
moje buildy:
https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng32-53db1e51-m.zip
https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng64-53db1e51-m.zip

uwaga, generuje e3d niekompatybilne ze starymi exe! nie wszystkie zmiany od tmj są zmergowane bo coś się zkaszaniło z kamerą i nie mam już do tego dzisiaj siły.

powoli zacząłem dostosowywać ścieżkę renderowania vbo do shaderów, może za kilka dni będą jakieś efekty.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 07 Marca 2017, 22:39:15
@Milek7: Mógłbyś proszę numerować swoje kompilacje, nadpisują się i nie ma jak porównywać ze starszymi.
@tmj: Wcisnąłem F4 i po chwili rozjechał mnie pociąg z toru obok. Mała korekta pozycji po za pojazdem w kierunku opuszczanego pojazdu, może 0,5 metra?
Ciekawostka (załącznik), plik gray.tga znalazłem też w oficjalnej paczce całościowej, stąd u mnie przy zaznaczeniu wczytywania tga, manewrowo się nie wysypało.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: loko w 07 Marca 2017, 23:05:20
Drawinowo-170306, misja EP09-005. Przejechałem tylko w jedną stronę na 170307b do momentu podpięcia się do drugiego składu. Mimo, iż "docisnąłem" lok do składu, między zderzakami była znaczna odległość. Ja też odnoszę wrażenie, że zawór hamulcowy m-sty działa wolniej. Temat znany, ale po zmianie kabiny, całe sterowanie oświetleniem (wszystkie tryby) odbywało się z klawisza "U". 
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: MaciejM w 07 Marca 2017, 23:11:43
Bo tak to jest zrobione: w lokomotywach, gdzie jest przełącznik pozycyjny (a nie złączanie każdego reflektora osobno) czyli w Traxxach, EP09, EU07-15xx, ST45 sterowanie oświetleniem to U (w lewo) i Shift+U (w prawo).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 07 Marca 2017, 23:15:58
@tmj: Wcisnąłem F4 i po chwili rozjechał mnie pociąg z toru obok. Mała korekta pozycji po za pojazdem w kierunku opuszczanego pojazdu, może 0,5 metra?
Bo trzeba patrzec, kiedy sie wysiada ;)
W tej chwili kamera jest ustawiana w odleglosci ~1m od boku lokomotywy, przysuwajac ja jeszcze blizej ryzykuje ze zwyczajne przetnie sie przez pudlo w niektorych przypadkach. Nawiasem mowiac, na to gdzie wyladujesz wplyw ma tez pozycja w kabinie w chwili nacisniecia F4 -- kalkulacja jest dla pozycji w fotelu maszynisty, jesli zamiast tego siedzisz gdzies po lewej stronie (w trybie debug albo chodzac dookola) to wyrzuci cie troche dalej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 07 Marca 2017, 23:20:12
Drawinowo? Dobrze trafiło, właśnie jadę w drodze powrotnej, lok jest luźno podpięty, ale zapiąć i jechać można. Załącznik. Co wydarzyło się dalej, bo nie napisałeś czy udało się spiąć, czy był wysyp? Jaka odległość była między zderzakami?

@tmj. Przyjąłem do wiadomości, będę się rozglądał. A może jakaś inteligencja aby przypadkiem nie wsadziło mnie do loka równolegle stojącego obok? Taka luźna dywagacja jak już nie będzie co robić.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 07 Marca 2017, 23:23:22
Coś jest wyraźnie nie tak z ucinaniem obiektów z boku kamery. Oprócz tych trójkątów jeziora, pojazdy też znikają. FPS=46, 1080p 16:9, ustawiłem kamerę by mi skład wjeżdżał z rogu monitora. Wagony renderowały się dopiero gdy były już ze trzy metry na ekranie. Wcześniej środek dynamica musiał być przynajmniej z pół km za kamerą by ten się nie wyświetlał.
Jeszcze gorzej jest, kiedy popatrzy się na skład "do góry nagami" lub pionowo w dół (obojętne z jakiej odległości), choć ten problem występował już w exe z paczki 16_01 i w patchu 16_05. W załącznikach ten sam skład z różnych perspektyw.
Edit.: Jeszcze lekko z boku - zał. 4.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 08 Marca 2017, 00:10:23
Całkowo _SN61, manewry wykonane poprawnie, przejezdne. Drawinowo EP09, dokończone z powodzeniem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 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.

Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 08 Marca 2017, 07:38:06
Jakim cudem na braku zwykłego przemnożenia możesz mieć takie różnice w wydajności? Musi być coś więcej od tego uzależnione i teraz jak się wyświetla freespot to nie robi jakiś bardzo kosztownych obliczeń. Co w takim razie to są za obliczenia?
Zająłem się ponownie tabelką prędkości. Jak narazie to nie działa w ogóle. Babrzę się z wyświetlaniem tabelki na ekranie bo zupełnie to zepsułem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 08 Marca 2017, 10:10:26
Wszystkim freespotom można ustawić maxdist=-1. Tu raczej nie ma wyjątków. Już nie mogę się doczekać testu tego pięciokrotnego wzrostu fps. :D
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 08 Marca 2017, 11:32:03
A ja odpalilem i musialem wyjsc z domu. W tej chwili usycham z ciekawosci a AI jedzie do Ostrowa. Po odpaleniu zanotowalem wzrost fps, ale mam za slaby sprzet aby byl az taki. Jesli na starcie mialem 30 do 35 to teraz bylo okolo 50. Wroce, to dokonam porownania.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 08 Marca 2017, 13:55:24
Jakim cudem na braku zwykłego przemnożenia możesz mieć takie różnice w wydajności?
Przemnozenie dotyczylo wszystkich objektow, wiec w praktyce jesli cos mialo wpisane widocznosc do 1km, to symulator "traktowal je powaznie" na dystansie niemal 28 km od kamery... a w scenach jest duzo objektow :x Nie wszystko bylo faktycznie rysowane, bo tam sa jeszcze dodatkowe limity ilosci obrabianych sektorow terenu itp, ale spowolnienie bylo.

Po odpaleniu zanotowalem wzrost fps, ale mam za slaby sprzet aby byl az taki. Jesli na starcie mialem 30 do 35 to teraz bylo okolo 50. Wroce, to dokonam porownania.
Zmiana bedzie do pewnego stopnia zalezala od scenerii -- np na Kaliskiej w Lodzi, patrzac 'w glab' dworca na poludnie, skok byl z 60 fps do ~90. 200-250 zaczal wyciagac na odcinku poza Lodzia. Ogolnie rzecz biorac, zmiana bedzie mniejsza w gesto 'zaludnionych' obszarach, wieksza na odcinkach gdzie te zaludnione obszary sa dosc daleko, i symulator (teraz) faktycznie przestaje sie nimi przejmowac.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: loko w 08 Marca 2017, 14:54:00
Co wydarzyło się dalej, bo nie napisałeś czy udało się spiąć, czy był wysyp? Jaka odległość była między zderzakami?
Ogólnie to skończyły mi się godziny i musiałem zawołać podmianę ;-) Udało się spiąć i zdążyłem jeszcze próbę zrobić, chociaż już wołali zanim jeszcze podjechałem pod skład, ale mi się zeszło z tymi światełkami. I niestety na tym musiałem zakończyć symulację. Odległość prawdopodobnie była taka sama jak na Twym skrinie, później mogę wrzucić swój zrzut.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 08 Marca 2017, 15:02:11
Nie wrzucaj, skoro było identyczne a ja dojechałem do końca, to nie ma problemu. No może wizualny i trzeba sprawdzić czemu tak jest. Nie wydaje mi się aby exe było temu winne.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 08 Marca 2017, 15:58:56
Jaki to pojazd? Może ma niezgodność modelu z fiz.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 08 Marca 2017, 16:12:08
EP09 Drawinowo. Loko jechal oryginalna dziewiatka, ja pojechalem 09-046 clasic. Dalem wyzej screen z widokiem sprzegu i zderzakow. Wygladala na luzno skrecona z wagonami.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 08 Marca 2017, 17:46:12
Chłopaki, serio zobaczcie co jest nie tak z exe na scenerii zwierzyniec_transport:
Odpalam scenerię, czekam na wyjazd, próbuję ruszyć. Cały test trwa góra 3 minuty. Efekt jest zabawny. Problem nie jest ze scenerią, bo na starych exe działa poprawnie. Myślę, że to ilustruje całkiem ciekawego i dużego buga.

Nie wiem czy ktoś już to zgłaszał (bo trochę mnie nie było), ale jak jest w Rainsted zaznaczona pauza na starcie, to zaczynamy pod lokomotywą ;) Dopiero po odpauzowaniu znajdujemy się w kabinie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 08 Marca 2017, 17:48:19
Cytuj
Zabawny
No wybacz, ale opis buga na Zwierzyniec transport jest nieco skąpy. Dorzuć coś.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: dymus w 08 Marca 2017, 18:04:21
Cytuj
Efekt jest zabawny
Przy ruszaniu jakąś magiczną siłą nasz skład zaczyna przyciągać drezynę, tak że wjeżdża na nasz skład. To było to zabawne czy coś mnie ominęło?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 08 Marca 2017, 18:14:39
Nie trzeba ruszać, wyjeżdża z Psiary Południe kilkanaście sekund po uruchomieniu scenerii. Tyle że nie wywołuje tego żaden event, a drezyna jest zahamowana..
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: art72 w 08 Marca 2017, 18:15:23
Nie wiem czy ktoś już to zgłaszał (bo trochę mnie nie było), ale jak jest w Rainsted zaznaczona pauza na starcie, to zaczynamy pod lokomotywą ;) Dopiero po odpauzowaniu znajdujemy się w kabinie.

Też tak miałem na dziewiątce w Drawinowie :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 08 Marca 2017, 18:20:39
Jeśli chodzi o drezynę, to było zgłaszane a ja potwierdziłem. Nawet dopytywałem, czy ktoś wziął temat pod lupę.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 08 Marca 2017, 19:15:21
Może to bug w samej drezynie jednak. Tak jak nie dające się wyłączyć syczenie w kiblu to błąd kibla. Na 99%. Poprawione exe ujawnia ukryte bugi w innych miejscach. Tak strzelam tylko, oczywiście. Przed chwilą przejechałem linię 053 (część osobową), nie wykryłem żadnych problemów. Może podejrzane było, że nie spaliłem silnika ani nie zniszczyłem obręczy na tych torach, bo po długiej przerwie zapomniałem gdzie są te pułapki i zareagowałem troszkę wolniej niż kierowca F1. Chociaż oczywiście to natychmiastowe niszczenie lokomotywy było zgłaszane wcześniej jako bug, więc teraz wygląda, jakby działało lepiej. Do 2 sekund na reakcję jest chyba realistycznym czasem, poprzednio jednak lokomotywa ulegała uszkodzeniu po ułamkach sekundy poślizgu. Następnym razem sprawdzę, czy jednak uda mi się zepsuć loka, bo po jakimś czasie (jakim?) powinien się jednak zepsuć.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 08 Marca 2017, 19:42:22
Drezyna jest wygaszona, zahamowana, a coś ją wystrzeliwuje ruchem przyspieszonym. Trzeba by obadać tory w jej punkcie startowym. Może coś tam jest dziwnego. Testowałem ją na TD i jeździ normalnie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 08 Marca 2017, 19:47:37
Tak jak nie dające się wyłączyć syczenie w kiblu to błąd kibla. Na 99%.
Syczenie kibla generalnie ma miejsce przy uruchomieniu symulatora z aktywowana pauza, bez pauzy jest, z tego co doswiadczylem, ok. Wiec technicznie bedzie to blad exe :)
Co do drezyny, to ja nawet nie wiem czy pliki ktore ja obsluguja sa wlaczone do kodu, chyba nie. Wydawalo mi sie ze to jest taki "Easter Egg" dlatego specjalnie sie jej nie przygladalem. Tak ze faktycznie, tam sie moze dziac wszystko.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 08 Marca 2017, 19:50:49
Ale to jest WM15. Silnik dumb, hamulec pneumatyczny oerlikona. Działa w pełni. A machajki mi nie psuj. Po coś model robiłem. :P
Pooglądałem tory gdzie startuje i nie widać tam żadnych dubli, czy niczego podejrzanego. Nie mam pomysłu co może być przyczyną.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 08 Marca 2017, 20:08:14
Powiedzcie czego brakuje... ;)

PS. Zmiana masy na 25,5 t (z obecnych 74 t) częściowo pomogła, ale nie wydaje mi się że to jest główna przyczyna.

PS2. Zauważyłem, że choć pojazd minimalnie się przesuwa (teraz, po tych zmianach), to koła się nie kręcą... dziwny poślizg?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 08 Marca 2017, 20:10:51
Ale to jest WM15. Silnik dumb, hamulec pneumatyczny oerlikona. Działa w pełni. A machajki mi nie psuj. Po coś model robiłem. :P
Pooglądałem tory gdzie startuje i nie widać tam żadnych dubli, czy niczego podejrzanego. Nie mam pomysłu co może być przyczyną.

Aha :) zobaczymy, na razie probuje naprawic wyswietlanie kabiny i pare innych rzeczy. Tego typu szalona predkosc to z reguly wynik rozjechanej kalkulacji sil przy zderzeniu, ale tam chyba nie ma sie z czym zderzyc?

edit:

PS2. Zauważyłem, że choć pojazd minimalnie się przesuwa (teraz, po tych zmianach), to koła się nie kręcą... dziwny poślizg?
Zobacz w errors.txt czy tam nie ma wzmianki o brakujacym wpisie animations, niektore mmd tak maja, i kiedys to dzialalo bo wpisywane byly wartosci domyslne, ale to z kolei powodowalo inne problemy, wiec prawidlowym podejsciem powinna byc naprawa tych .mmd  Objawem (oprocz wpisu w errors) jest wlasnie brak krecacych sie kol i jakichkolwiek innych animacji w pojezdzie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 08 Marca 2017, 20:22:38
Jak dałem prędkość początkową 1 km/h aby pojazd był uruchomiony przez AI, to koła kręcą się wówczas normalnie i normalnie się zatrzymuje, bez dalszego przesuwania co chwilę o centymetry.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 08 Marca 2017, 20:24:38
Ta drezyna jest dziwna, zamarzły jej szyby, ale w końcu to zima. Zatrzymałem ją i stoi tam gdzie powinna. Nie edytowałem jej masy, lecz w trainsecie zmieniłem wpis na nobody (było headdriver). Tym sposobem jadę suczką odprowadzić tabor na złom.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: AtapiCl w 08 Marca 2017, 20:46:23
Wstawiłem ST45 zamiast WM15 dając mu także headdriver i prędkość początkową 0 - efekt jest taki sam, rozpędza się na poślizgu i wbija w nasz skład. Danie prędkości początkowej <> 0 lub danie nobody rozwiązuje problem. Z ciekawości zamieniłem też punkty początku i końca toru (kiedyś pamiętam jakieś jaja z tym były w pewnych przypadkach), ale tabor wystrzeliwuje na poślizgu w drugą stronę, a więc nie ma to znaczenia.

EDIT: cały czas też przed wystrzeleniem słychać dźwięk piasecznicy. Wstawiłem EU07, które co prawda nie wystrzeliwuje, ale piasecznice ma non-stop odpaloną.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 08 Marca 2017, 20:56:47
Cały ten zwierzyniec... AI zatrzymuje się w połowie drogi bez powodu. W tabeli skanowania widnieje 0km/h, ale powodu nie widać. Podglądałem w STV jakie jest pochylenie i tarcie i nic. Po tym co napisał Tomek wydaje się, że błąd siedzi w scenariuszu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 08 Marca 2017, 21:21:24
AI piaskuje bardzo dziwacznie. Przy dodaniu dźwięku do tego dopiero wylazło. ...albo dźwięk się nie wycisza. Reset ai w takiej sytuacji pomaga.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 08 Marca 2017, 21:24:28
To samo jest z dźwiękiem syreny ET42, AI potrafi trąbić non stop, zgłaszałem to.
Jeszcze jedna wiadomość jest taka, że na exe od @Milka7 WM15 też robi co chce i na exe 170205 a więc z początku konwersji też jest nieposłuszna.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 08 Marca 2017, 21:39:32
Witam.
 Uruchomiłem na najnowszym exe 170308 kaliską. Fps rzeczywiście bardzo się poprawił. U mnie na poziomie ok 200-300 procent. Ale żeby nie było tak różowo, szyny zmieniły teksturę, z szyn na podsypkę. Wygląda że problem nie dotyczy flexów i chyba łuków. Sprawdzałem na TD i mam to samo. Potwierdza ktoś u siebie ten błąd?
Pozdrawiam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 08 Marca 2017, 21:41:38
Nie potwierdzam, ale może wyłącz wyświetlanie VBO w rainsted.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 08 Marca 2017, 21:44:35
Krzysiek, pomogło dzięki. Czyli uruchomiać bez ptaszka przy VBO.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 08 Marca 2017, 21:55:11
Tak, bez ptaszka. Wyświetlanie VBO jest robione przez @Milek7, ale jeszcze jakiś czas upłynie zanim skończy.
ED:
Przywróciłem wpis do fizyki usunięty przez @Ra, teraz grzecznie stoi na miejscu. W załączniku plik wm15.fiz z przywróconym wpisem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: mareczek w 08 Marca 2017, 22:31:42
1) Poszedł radiostop. Powietrze zeszło, chcę popełnić i nie chce. Dojdzie prawie do 0,3 ale nie przeskoczy. Wszystkie węże sprawdzone (skład rozłączony, potem ponownie połączony), nic nie dało.
2) W ramach rozrywki dałem insert na czoło mojego loka od strony gdzie nie ma żadnych wagonów i poleciał crash.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 08 Marca 2017, 22:35:27
W ST45 hamulec stracił głos. Tzn nie ma dźwięku przy hamowaniu, przy odhamowaniu jest. Dziwne, jutro sprawdzę dokładniej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 09 Marca 2017, 00:15:55
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
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 09 Marca 2017, 07:06:46
Z dzisiejszych zabawek wstępna koncepcja wyświetlania tabelki prędkości. Jak to zobaczyłem to się zacząłem zastanawiać czemu mnie tak denerwuje, ale już miałem "następna stacja: Kraków Płaszów" i zbierałem się w ekspresowym tempie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 09 Marca 2017, 12:49:19
Światła semaforów wyglądają dużo lepiej. Nie widzę żadnych problemów, no może poza tymi starymi, z opcją pauzy. A nie można by tego zrobić tak prowizorycznie, że po odpaleniu z opcją pauzy odpauzować na pół sekundy i zatrzymać? Wtedy nie byłoby innego działania z pauzą i bez.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 09 Marca 2017, 13:35:22
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
Nie mam żadnych zastrzeżeń, wszystkie powyższe aktualizacje dla mnie poprawiają komfort wizualny, są trafione. Brawo. Wzrost wydajności w FPS i czas wczytywania scenerii jest znakomity, ciekawe, czy było to do uzyskania w Borlandzie? Przepisywanie na C++ wygląda na opłacalne.
@Milek7, Twoje exe odpala się i nie wykazuje większych błędów niż exe @tmj. Oczywiście wersja 32 bitowa. Na dziś kończę testowanie, nabyłem nowy dysk i potrzebuję czasu na przepisanie danych z komputera z dysku, który ledwo zipie.
Ze znanych błędów, część wpisana jest do bugtrackera, część pamiętamy. Drobne poprawki nie będące błędem a jedynie kosmetyką działania aplikacji można zostawić na później, bo jak widzę rysują się odmienne poglądy na działanie funkcjonalności.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 09 Marca 2017, 13:40:44
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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 09 Marca 2017, 14:14:38
Sorki za pytanie o być może coś oczywistego, ale o co chodzi z 64-bitowym exe? Czym się różni? Od strony testowania - utrudnienie, bo trzeba wszystkie dll-ki nadpisać, żeby działało (i wtedy nie działają 32-bitowe exe). Czy 64-bitowe exe to MaSzyna faktycznie robiąca użytek z 64-bitów, tzn szybsze operacje na liczbach typu double zamiast float itd? Czy potrzebne jest porównywanie w testach obu wersji pod kątem wydajności? Czy na razie to tylko wersja bazowa która ma się tylko skompilować jako x64, a zmiany dotyczące wydajności są zaplanowane na później?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 09 Marca 2017, 14:46:25
Wersja 64bit to glownie umozliwienie exe korzystania ze znacznie wiekszego obszaru pamieci. Ewentualne przyspieszenie mogloby sie pojawic przy starszych kompilatorach, ktore generowaly 'stary' kod dla operacji zmiennoprzecinkowych w trybie 32-bit, a wlaczaly uzycie SSE(2) przy kompilacji 64-bitowej, ale zdaje sie, ze na VS2013+ SSE jest uzywane domyslnie takze w trybie 32bit.

Ale porownanie na pewno warto zrobic, chocby dla pewnosci :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 09 Marca 2017, 14:46:59
Nigdy nie mam tak, abym na komputerze miał jeden system operacyjny. Zwykle jest XP i WIN7, są oczywiście na osobnych dyskach. XP32 bitowe, wersja nie oemowa. WIN7 jest 64 bitowy. Zwykle mam 3 dyski, więc zawsze jeszcze jakaś instalka na czysto może być w zapasie. Stąd nie mam problemu i konfliktu między poszczególnymi bibliotekami i paczkami, czy exekami. Ponadto, aby nie nadpisywać bibliotek czy innych plików mam zwykle kilka (czsem naście) paczek do testowania. Prawda, nie każdy dysponuje 3Tb miejsca w pamięci masowej, ale przy rozsądnym gospodarowaniu 1Tb też wystarczy. Zbieram wszystko co ukazało się do symulatora łącznie z unofami, posiadam około 600Gb fotografii, ale jak czegoś jest się fanem, to miejsce na to musi się znaleźć.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 09 Marca 2017, 14:49:25
Nie, tu nie chodzi o wydajność. Plusem jest możliwość zajmowania więcej niż 4GB pamięci.
Głównie to jest testowane pod przyszłą wieloplatformowość, bo o ile na windowsie obecność WoW64 jest pewna, to np. na linux nie każdy musi mieć zainstalowane w systemie biblioteki dla x32.
Od strony wydajności mogą być drobne różnice, ale naprawdę niewielkie. (na 32bit wskaźniki zajmują mniej, więc więcej struktur mieści się w cache cpu i jest mniej cache missów, z drugiej strony x64 wymaga obecności rozszerzeń SSE2 więc są właczone na tych exekach, ale oczywiście kosztem kompatybilności ze starymi cpu można włączyć nowsze rozszerzenia także dla x32).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 09 Marca 2017, 16:45:09
Właśnie przejechałem Drawinowo na ostatnim x64, brak uwag poza jedną, ze znikaniem obiektów, ale z tego co czytałem już poprawione. Na Drawinowie ostro spada FPS w Grabówku i Włodowicach. Ale to było od zawsze tam.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 09 Marca 2017, 18:21:55
Druga wersja wyglądu tabelki.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 09 Marca 2017, 18:24:03
Dwie kolumny imho bardziej czytelne.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 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 :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 09 Marca 2017, 18:52:35
W ten sposob calosc bylaby chronologiczna.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 09 Marca 2017, 19:05:01
Jeszcze wersja dwutabelkowa z kolorowaniem.
Rozdzieliłem tabelki wskaźników i torów żebym nie musiał robić iluśtam if-ów w przechodzeniu po jednej tabelce. Nie chcę tego mieszać teraz i sortować w każdej klatce. Oczywiście jest opcja powrotu do tego co było, ale moja wersja umożliwia wstawianie wskaźników w dziwnych kolejnościach i nieprawidłowo przypisanych do torów.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 09 Marca 2017, 20:20:46
merge z tmj i skrobnąłem coś tam w malowaniu trajektorii na vbo

https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng32-39412833.zip
https://milek7.pl/.stuff/eu07exe/eu07%2B%2Bng64-39412833.zip
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 09 Marca 2017, 21:13:09
Panowie pytanko. Dużo był zmieniany kąt widzenia? Robię te poprawki ustawienia kamer dla wszystkich pojazdów i testowałem to na waszym exe c++ i było wszystko okej, natomiast po przejściu na borlandowe, jestem dość głęboko w ścianach. Pytanko czy tak to zostawić czy robić pod stare exe, chociaż raczej te poprawki nie zostaną wprowadzone wcześniej niż wyjdzie nowa paczka całościowa czy też patch.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 09 Marca 2017, 21:14:18
Jeszcze pytanko czy zależy to od proporcji ekranu i ustawionego fov? Co by dla jakiejś konfiguracji nie wylądować za ścianą.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 09 Marca 2017, 21:17:25
Domyslny kat widzenia chyba nie byl zmieniany (zmiana zalezy of wpisu fieldofview kat w .ini, natomiast zwroc uwage ze poziomy kat widzenia zalezy od proporcji okna symulatora, i 16:9 pokazuje w poziomie wiecej niz 4:3
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 09 Marca 2017, 21:21:28
Tylko jest różnica patrząc na ścianę prostopadle. Na waszych exekach widać ścianę, a na borlandowych jej nie wyświetla. Jakby wokół kamery była sfera ucinająca renderowanie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 09 Marca 2017, 21:22:12
Różnica jest ogromna.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 09 Marca 2017, 21:25:25
Aha, moze tak byc, bo kamera w openGL ma zdefiniowany zakres minimalny, i nie renderuje niczego, co jest blizej. W przepisanym exe ten zakres minimalny jest definiowany na ~10 cm, w starym exe bylo chyba 20.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Waldi 1978 w 09 Marca 2017, 21:37:23
Linia 61 towarowy1  problem. Nie wiem czy to wina exe 170309, czy ogólnie tej  trasy.
Po wyjeździe z Herbów Nowych dostałem s1. Jazdy ok 3 min, potem czekałem tam ok 20 min i dałem sobie spokój.
EDIT
@tmj
Tam nic nie widać :) Obleciałem  tył i przodek w dali stoi tylko jakiś towarowy na s1.


 
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 09 Marca 2017, 21:40:11
Tez nie wiem czy to problem trasy czy exe, ale tak mowiac ogolnie, jesli przytrafi sie cos takiego to warto wysiasc z lokomotywy i przeleciec sie z wcisnietym ctrl wzdluz toru, zeby sprawdzic czy tam cos z przodu siedzi i blokuje :)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 09 Marca 2017, 21:42:38
Odpaliłem to L61_towarowy, sprawdzę. Z tym lataniem po scenerii jak jest ciemno to jest dolna część pleców. Obecnie nie umiem, lub nie potrafię zrobić dnia w Quarku. Nawet jak wywale wszystkie wpisy atmo i time, w rainsted wskaże o co mi chodzi, to i tak dostaje ciemność. No chyba, że w kamerze zrobicie szperacz;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 09 Marca 2017, 22:11:38
Latarkę do ręki jak w Farmin Simulator 2017 xd
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 09 Marca 2017, 22:19:33
W mailu podam adres na który można mi ją wysłać. Jeśli nie będzie możliwości rozłączenia zależności Czas - Światło - rozkład jazdy, to ja wypadam z testowania nocnych scenerii. Sprawa jest prosta, jeśli zablokować i wymusić jasność, to symulator zaczyna wyświetlać 10,30. Nocne rozkłady i eventlaunchery nie będą działać. Po ciemku głano, nic nie widać, to żadnego korka nikt nie wypatrzy. Owszem, potwierdzam błąd L61_towarowy_1, wyjeżdżamy i na następnym stoimy i kwitniemy.
W związku z tym, w trybie pilnym, nadzwyczajnym, proszę przywrócić możliwość włączenia słońca, nawet wtedy, kiedy jest godzina 1 w nocy. Tryb debug mode powinien, o ile nie musi ułatwiać testy. Proszę o stosowną odpowiedź.;)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 09 Marca 2017, 22:23:44
W jakiej odległości jest księżyc? Wychodzi przez chmurami na moim skyboksie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 09 Marca 2017, 22:26:44
Obecnie nie umiem, lub nie potrafię zrobić dnia w Quarku.
Najszybciej chyba to przejsc do debug mode (ctrl+shift+f12 jesli nie bylo uruchomione w debug) i przytrzymac shift + F1, zeby popchnac zegar do przodu.

edit: ale jesli jest zapotrzebowanie, to moge o czyms pomyslec.

W jakiej odległości jest księżyc? Wychodzi przez chmurami na moim skyboksie.
Ksiezyc jest jeszcze z nieba ze starego exe, wiec absolutnie nie odpowiadam za jego zachowanie :)  Najlepiej zmienic wpis nieba na skydome_clouds.t3d a o starym zapomniec, chyba ze ktos lubi ogladac dwa slonca itp.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 09 Marca 2017, 22:27:42
Ale to rozsypie rozkłady i eventlaunchery, nie? Krzyś chciałby dać opcjonalne światło niezależnie od godziny w debugu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 09 Marca 2017, 22:28:46
Antek, jest ciemność i nic nie widać. Jak Ty potrafisz tam coś wypatrzeć, to próbuj. Mogę sobie rożświetlić siftem + F1, mogę zablokować ciemność wyłączając Time, ale wiesz doskonale, że posypią się rozkłady. Dla mnie przywrócenie widności w nocy bez ruszania czasu jest bezdyskusyjne, nie powinniśmy psuć oczu na wypatrywanie czegoś na ekranie.
Obecnie nie umiem, lub nie potrafię zrobić dnia w Quarku.
Najszybciej chyba to przejsc do debug mode (ctrl+shift+f12 jesli nie bylo uruchomione w debug) i przytrzymac shift + F1, zeby popchnac zegar do przodu.
edit: ale jesli jest zapotrzebowanie, to moge o czyms pomyslec.
Tak możemy oglądać statyczne obiekty, obserwacja korków i dynamiki jazdy nie jest możliwa. Bardzo proszę:)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: loko w 10 Marca 2017, 05:49:41
Kaliska_Cegielski, pos Cegielski, EXE eu07++170309. Przejezdna do końca, FPS rzeczywiście na plus, aż muszę uruchomić na EXE z paczki i porównać. Z tego co zauważyłem to na wyjeździe z Opatówka słup i sieć były odwrócone (wcześniej nie rzuciło się mi to w oczy a nie wiem czy było zgłaszane) oraz smuga wydaje się do poprawy - w Kaliszu oświetlała sufit zadaszenia peronowego. Z tego co się orientuję, to reflektory w pojazdach w realu nie mają takich ustawień.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 10 Marca 2017, 10:14:25
Najpierw podziękuję za ctrl+F7, wspaniała sprawa.
Linia 61 towarowy1  problem.Nie wiem czy to wina exe 170309 czy ogólnie tej  trasy.
Po wyjeżdzie z Herb Nowych dostałem s1. Jazdy ok 3 min czekałem tam ok 20 min i dałem sobie spokój.<ciach>
Nie ma żadnego korka. Jeśli zdecydujemy się pojechać mimo S1 to, to drogę mamy ułożoną a nastęnpe światła pozwalają nam jechać. Po złamaniu S1 dokończyłem scenariusz. Największa ciekawostka, to samo jest na exe z paczki całościowej, czyli nadal oficjalnym.
Nie pisałem tego scenariusza, on był przejezdny a w PC nie jest i szukać powodu S1 na HR_R12 nie będę.
Kaliska_Cegielski, pos Cegielski, EXE eu07++170309. <ciach> smuga wydaje się do poprawy - w Kaliszu oświetlała sufit zadaszenia peronowego. Z tego co się orientuję, to reflektory w pojazdach w realu nie mają takich ustawień.
O oświetleniu była mowa, jeśli jeden z wierzchołków trójkąta załapie się na oświetlenie, to świeci cały trójkąt. Znana przypadłość, będzie poprawiona jak zapowiadają exemajstrowie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 10 Marca 2017, 10:27:14
Niestety nie jestem tak dobry i szybki jak nasi spece i tak popsułem tabelki że mam crashe ;) Popołudniu kolejna sesyjka z próbą dowiedzenia się co jest nie ten teges.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 10 Marca 2017, 17:31:17
Nowe uaktualnienie w nowym watku ( http://eu07.pl/forum/index.php/topic,28920.0.html ) zeby nie trzeba sie bylo przekopywac przez 40 stron. W zasadzie bez zmian od wczoraj, oprocz dodanej mozliwosci zmiany FoV przy uzyciu Ctrl + kolko myszy, w trybie debug. Aktualna wartosc FoV jest tez w tym trybie wyswietlana na ekranie F8, powinno ulatwic dobranie wartosci do indywidualnych preferencji itp.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 10 Marca 2017, 19:49:14
Super z tym wątkiem. :) Czemu tylko w debugu? Jak nie sprawia problemów, to w podstawowym też by się przydało, zwłaszcza jak rewizja pozycji kamer nastąpiła.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 10 Marca 2017, 19:51:57
Popieram, w trybie normalnym też będzie się można wygodnie usadzić jak kto lubi.
Jak można, to prosił bym o sprawdzenie działania ctrl+r. Jakby nie zatykał dziury w PG (przewód główny powietrza), po użyciu ctrl+pause.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 10 Marca 2017, 19:54:57
Sprawdziłem na exeku z ósmego przed chwilą i działa. Wyłączamy radyjko, popełniamy loka, włączamy radyjko i trzyma ciśnienie. Samo kliknięcie on-off to za mało.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 10 Marca 2017, 19:57:53
Czemu tylko w debugu? Jak nie sprawia problemów, to w podstawowym też by się przydało, zwłaszcza jak rewizja pozycji kamer nastąpiła.
ZTCP to rolka jest przez niektorych uzywana do kontroli nastawnika itp, wiec wolalbym tutaj za bardzo nie mieszac. To i tak prowizorka do czasu gdy bedzie normalny ekran z ustawieniami, ktory powinien przejac tego typu sprawy. (a przelaczyc debug na szybko ctrl+shift+f12 to chyba tez nie taki straszny problem)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 10 Marca 2017, 20:00:23
Ale jak jest z controlem to spoko. Jak ktoś używa takiej kombinacji, to sobie przekonfiguruje na inny klawisz kontrolny. Chciałbym jednak by to było dla kowalskiego dostępne. Dla nas włączyć debuga, pokręcić rolką ,wyłączyć to nic, ale on jak nie zgłupieje, to przestraszy się nazwy debugmode.
Przetestowałem efekt i jest spoko, zakres nie powoduje dziwnych efektów w żadnym z ekstremów. Po mojemu to mogą sobie kręcić do woli.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 10 Marca 2017, 20:02:46
No ja wlasnie mam watpliwosci czy to jest cos do zostawienia w rekach zwyklego uzytkownika ;)  ale mozna zmienic, zobaczymy.

edit: aha, a tak zupelnie z innej beczki. Przelacznik przyciemnienia reflektorow, na ile to w rzeczywistosci przyciemnia swiatla? O polowe, mniej, wiecej?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 10 Marca 2017, 20:41:57
Zrobiłem update do najnowszej wersji i niestety, w przeciwieństwie do reszty zanotowałem spadek FPS o 50% na integrze intela. Wygląda, że na stałe włączone jest wygładzanie krawędzi.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 10 Marca 2017, 20:53:43
No ja mam skok na Bałtyku z 70 na 170 do 220FPS.
A teraz najważniejsza informacja jak dla mnie i pewnie też dla tych co nie wiedzieli. Po radio stopie można odhamować loka i skład pod warunkiem że jesteśmy w trybie normalnym. W trybie debug mode, nie uruchomimy składu, bo przewód główny nadal jest dziurawy i się nie napełni. W obu trybach sprawdziłem loki: ET22 EU07 i EP09. Tak ma być?
Zoom pod ctrl + scroll, jest genialny.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 10 Marca 2017, 21:13:46
Powiedzmy że prace nad shaderami powoli... przesuwają się do przodu :D
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 10 Marca 2017, 21:17:19
Dobrze idzie, trzymaj tak dalej. Obciąłem paznokcie, co by dziur w dłoniach nie wydrapać.:)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 10 Marca 2017, 21:17:44
Zrobiłem update do najnowszej wersji i niestety, w przeciwieństwie do reszty zanotowałem spadek FPS o 50% na integrze intela. Wygląda, że na stałe włączone jest wygładzanie krawędzi.
Tzn. multisampling? To sie chyba da wylaczyc przy ustawieniu parametru w .ini na 0 albo jakos tak. Ale nie probowalem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: 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ć.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: miko22 w 10 Marca 2017, 21:30:18
Przelacznik przyciemnienia reflektorow, na ile to w rzeczywistosci przyciemnia swiatla? O polowe, mniej, wiecej?
Pomierzyłem, policzyłem i wyszło mi, że tak - moc reflektorów zmniejszana jest do ok. 50%. Przynajmniej w ET41 i pochodnych ;) (EU06, EU07, EP07, EP08, pewnie też ET22 - w innych nie wiem).
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 10 Marca 2017, 22:30:51
Dzieki, mniej wiecej tyle ustawilem, czyli moze dobrze bedzie.

Jak w ini na 0, to jak to się ma do suwaka w rainsted, gdzie jest priorytet. Nie wspomnę o ustawieniach sterownika karty graficznej bo tam priorytety można nadać.
Rainsted chyba ustawia ten sam parameter, tylko wyswietla wartosc 0 jako "1" itd. Jak to sie ma do ustawien karty to nie wiem, bo to chyba zalezy tez w czesci od oprogramowania karty -- np NVidia ma w opcjach odrebne ustawienia "popraw jesli exe ustawia mniej" i "ustaw tyle, i niewazne czego chce exe".
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 11 Marca 2017, 06:36:43
Żeby nie było, to porównanie z ilością FPS:
1. Stare exe 482
2. Exe na c++ bez zmian Milka (mniej więcej wersja z 27.02)
3. Wersja na GLFW (wersja z wczoraj)
Uruchamiam z tego samego katalogu, z tymi samymi ustawieniami.
ED:
Zmieniłem ustawienie na MSAAx8 (multisampling 3).
482: 30 FPS
c++ 2702: 30 FPS
c++ glfw: 20 FPS

Dodatkowo glfw na starcie nie ma MSAA a po paru sekundach ono się włącza niezależnie od ustawienia w ini.

ED2:
Pobawiłem się trochę i na wersji z 27.02 na MSAAx8 wyciągam 45 FPS, a na wersji na integracją z glfw już tylko 30 FPS.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 11 Marca 2017, 10:08:16
na wersji z glfw vsync włączony czy wyłączony?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 11 Marca 2017, 10:40:57
Tak tez wlasnie podejrzewam, ze chyba jest wlaczony. @Firleju, sprawdz na ostatniej wersji (0311) tam jest wylaczony domyslnie, albo wpisz vsync no w .ini?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: CX MANIAK w 11 Marca 2017, 12:02:30
Witam.
U mnie odptaszkowanie synchronizacji na najnowszym exe podbija fps na TD do prawie 200. Na exe z paczki stoi jak zaklęte na 60. Pomimo pracy monitora na 75Hz.
 Generalnie spadek zaobserwowałem po wprowadzeniu GLFW. Ale tylko do czasu poprawy babola z liczeniem obiektów, który wykrył @ Tmj. Na wersji najnowszej mam minimum 30fps w Ostrowie na początku symulacji, gdy kamera skierowana jest od czoła na stojące składy. Czyli w polu widzenia ponad setka wagonów, kilka loków i mnóstwo torów i innych obiektów. A wcale nie mam jakiegoś wypasionego komputera. Stary biurowiec HP na E7200 z dodaną grafiką GTX460 ( ledwo zipie) i 4 Gb ramu. Zastanawiające jest, że u kolegów mających czasem nawet nowsze sprzęty, jest na odwrót. A może mój komputer lubi po prostu Maszynę:-)
Pozdrawiam.
 
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 11 Marca 2017, 12:27:08
GF9600GT + 4GB ram + IntelE6300 +XP. Jeszcze starszy, albo może raczej słabszy sprzęt, na starcie w kiblu w Ostrowie mam 41FPS załącznik. Na TD ponad 300. To wszystko jest na 170311. Ja jestem pełen uznania dla exe i swojego komputera.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 11 Marca 2017, 14:09:39
Zauważyłem taki błąd działania oświetlenia który ilustrują 2 poniższe zrzuty:
Po zapaleniu światła w kabinie teren na zewnątrz staje się jakby oświetlony i lepiej widoczny, podczas gdy powinno być dokładnie odwrotnie.
Światło odbite od szyby dodaje się do jasności obiektów na zewnątrz. Nie wiem czy coś się da z tym zrobić, bo tak chyba było od początku, ale jak już ktoś rusza te światła i poprawia, to może nie byłoby to takie niemożliwe do poprawienia.

Drugi błąd też jest związany z oświetleniem: w SN-61 nie działają lampy. Tzn jak się wyjdzie na zewnątrz to wyglądają na zapalone, ale nie oświetlają terenu. Po prostu nie ma żadnego efektu po zapaleniu światła. Testowałem na jedynej misji z SN-61, oczywiście dla porównania na tej samej misji wstawiłem stonkę zamiast SN-61 i oświetlała poprawnie.

Jeśli chodzi o działanie lamp, to chyba obecne rozwiązanie jest tymczasowe, więc może nie ma sensu zgłaszać uwag do niego. Gdyby był, to bym zgłosił, że znaki We8 i We9 są niewidoczne w nocy. Tzn migają na tak krótko, że bardzo trudno je zauważyć.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 11 Marca 2017, 14:13:54
SN ma tylko dwie lampy, wiec ma prawo świecić gorzej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 11 Marca 2017, 14:53:57
Ale ona w ogóle nie świeci. Porównywałem z SP42 na zapalonym tylko prawym reflektorze.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 11 Marca 2017, 16:04:22
Potwierdzam, brak świateł w SN61. Dojeżdżam do wagonu i żadnego oświetlenia (w załączniku). Za to jaki FPS.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 11 Marca 2017, 17:23:58
SN61 nie ma freespotów do świateł. Czy to może być tego wina?
Zauważyłem też, że auta nie świecą, ale nie wiem czy one mają animowane światła nawet. No i może nawet lepiej tak, niż by kradły sloty świateł pociągom.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 11 Marca 2017, 19:04:36
Wydaje mi się, że niektóre auta świecą. Nie mam pewności.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 11 Marca 2017, 19:13:06
Tak tez wlasnie podejrzewam, ze chyba jest wlaczony. @Firleju, sprawdz na ostatniej wersji (0311) tam jest wylaczony domyslnie, albo wpisz vsync no w .ini?
Wbiłem vsync no (chociaż teoretycznie sprawdzam na ostatniej wersji z repo). MSAAx8: 27.02 45 FPS, 11.03 30 FPS. 02.03 (glfw integration) 40FPS
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 11 Marca 2017, 19:20:31
Hmm troche dziwnie. Jesli to nie problem, moglbys jeszcze sprawdzic wydajnosc na 03.08? W 09+ wlaczone zostalo wygladzanie punktow, i moze akurat to gryzie sie ze starszym sprzetem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 11 Marca 2017, 19:24:03
Wysyp na Quarku. Wersja Ra 08.02.2017.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 11 Marca 2017, 19:59:19
Ty masz crash a ja mam tak, jak na screenie. Odpala się u mnie każdy scenariusz.
ED:
Powinienem dopisać, że tak mam na exe 170311 i na tym borlandowym z paczki całościowej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 11 Marca 2017, 20:15:56
Hmm troche dziwnie. Jesli to nie problem, moglbys jeszcze sprawdzic wydajnosc na 03.08? W 09+ wlaczone zostalo wygladzanie punktow, i moze akurat to gryzie sie ze starszym sprzetem.
Winny jest commit camera frustrum
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 11 Marca 2017, 21:30:52
Ok, ale commit ma polaczone zmiany kalkulacji widocznosci i wygladzanie punktow, natomiast w uaktualnieniach wydanych w watku bylo to podzielone -- kalkulacja widocznosci weszla w 3.08, a wygladzanie punktow w 3.09  Dlatego specjalnie pytam, czy jest jakas roznica w wydajnosci, przy porownaniu tych dwoch exe, bo moze latwiej da sie w ten sposob wylapac, co sprawia u ciebie problem.

(albo mozesz po prostu w world.cpp wykomentowac
glEnable( GL_POINT_SMOOTH );
i porownac, jesli tak jest prosciej ;d
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 11 Marca 2017, 22:16:39
W 170211 coś było zmieniane w znikaniu obiektów. No to melduję, że dynamiki wyświetla do góry nogami, ale przyduże trójkąty terenu nadal znikają jak znikały.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 11 Marca 2017, 22:20:26
Wysypik w załączeniu. To co zwykle czy jakaś odmiana? Tym razem pracowałem na luźnym komputerze, więc brak pamięci nie wchodzi w rachubę.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 11 Marca 2017, 22:27:43
Nie, to inny blad :)  Zeby bylo smieszniej, ten sam ktory trafil sie Stele kilka postow wyzej. Czy to moze tez na tym nowym Quarku? Nie bardzo wiem skad sciagnac, wiec trudno sie przyjrzec.

przyduże trójkąty terenu nadal znikają jak znikały.
Trojkaty terenu to inna czesc kodu do rysowania, probowalem sie temu dzisial przyjrzec, ale tylko na placz mi sie zebralo :|  okazuje sie ze teren jest teoretycznie podzielony na segmenty, ale co akurat w segmencie laduje, a co poza nim, to juz zupelnie inna bajka, i bez przepisania w zasadzie od nowa nie wiem, czy sie kiedykolwiek wyprostuje. Tyle dobrego, ze przy okazji zerknalem na zwiekszanie zakresu rysowania w zaleznosci od fps, ale moglo byc wiecej.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 11 Marca 2017, 22:29:10
Quarka testuję w wersji http://rainsted.com/warsztat/Quark/quark-170208.7z Bo taka (po drobnych przeróbkach dekoracji joeya) ma iść do paczki, chyba że Ra uwinie się ze zmianami układów torowych wcześniej.

Cofam wszelkie oskarżenia o skopanie wyświetlania tri z boku. To ja ślepy byłem, na borlandzie jest identycznie. Dodatkowo część jeziorek miała ograniczony zasięg wyświetlania, ale to nie pomogło na widoczność boczną. Mam je w maksie to zwiększę teselację i tyle. :) Jeszcze raz przepraszam za sianie zamętu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 12 Marca 2017, 00:44:09
Nie, to inny blad :)  Zeby bylo smieszniej, ten sam ktory trafil sie Stele kilka postow wyzej. Czy to moze tez na tym nowym Quarku? Nie bardzo wiem skad sciagnac, wiec trudno sie przyjrzec.
Nie, na tej samej misji i scenerii co poprzednio.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 12 Marca 2017, 01:00:08
Aha. Krzak byl gdzies przy skanowaniu tabelki predkosci, wiec na razie odpuszcze sobie tropienie go, bo moze zginie razem z reszta skanowania, gdy Firleju skonczy swoja wersje. Z tego co pamietam to chyba raz mi sie losowo trafil przez caly czas dreczenia exe, wiec wyglada na dosc rzadki/losowy przypadek.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 12 Marca 2017, 06:40:40
Hej, ale u mnie symulator nigdy nie ma >60 FPS, bo używam opcji vsync on. FPS to nie jest dobre kryterium. Już raczej jakiś wewnętrzny czas renderowania klatki w milisekundach, niezależny od ustawień karty graficznej, sterownika i systemu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 12 Marca 2017, 07:33:55
170312, Bałtyk, Kaliska. Żadnych uwag, wszystko zadziałało tak, jak powinno.
Uwolniłem monitor od synchronizacji, skoro można. Kryterium ilości FPS zawsze było wyznacznikiem wydajności.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 12 Marca 2017, 07:51:04
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. Niestety ogromne pogorszenie jakości obrazu i to wcale nie na stacjach, które wyglądają tak samo, tylko jadąc przez las i wieś, gdzie miałem zawsze 60FPS na starym exe.

Pogorszenie polega na wyskakiwaniu dużych elementów typu ściany lasu, budynki i grupy drzew przed kamerą. Proszę, zmniejszanie widoczności obiektów kompletnie nic nie daje dla wszystkich współczesnych a nawet dość starych kart graficznych. To nie dlatego MaSzyna przycinała. Tak jak mówiłem - przycinanie występowało u mnie dokładnie identycznie dla 2 różnych kart graficznych (bardzo stary Radeon i dużo nowszy GTX960), do tej samej wartości i w tych samych miejscach - na dużych torowiskach. Jadąc przez wieś miałem 60FPS nawet na zintegrowanym Intelu we w miarę nowym laptopie.

Najlepiej dodać opcję w konfiguracji, tzn ini, drawing distance, bez limitu, albo z limitem 10km. Wtedy po szybkich testach będziemy wiedzieć co wpływa na FPS na różnych kartach graficznych, a co nie.

I jeśli już modernizujemy MaSzynę, to modernizacja raczej nie powinna się koncentrować na muzealnych komputerach. MaSzyna była muzealnym symulatorem dla muzealnych komputerów. Największą jej wadą był kompletny brak wsparcia dla nieco nowszych (a przez nowsze mam na myśli takie z 5-6 letnie) komputerów. Całe szczęście to się da pogodzić dzięki konfiguracji. Jak ktoś chce sobie MaSzynę odpalić na kalkulatorze, nie ma sprawy - może sobie wyłączyć wszystkie detale graficzne i pójdzie. Jak ktoś ma kilkuletni sprzęt (a nie kilkunastoletni) - włączy sobie wszystko na maksa i też będzie zadowolony.

Od początku mojej przygody z MaSzyną zauważyłem niemal kompletny brak wpływu włączonych poprzez sterownik karty graficznej detali a FPS. Obojętnie czy był to Radeon z seri 4, 5, 6, czy NVidia - ustawienia grafiki w ogóle nie wpływały na FPS. Mało tego - ten sam efekt obserwowałem przed i po zastosowaniu mojego patcha, który ustawiał wszystkim obiektom widoczność -1. Brak wpływu na FPS, równy przed i po (chociaż różnica w delatach grafiki była wyraźnie zauważalna). Pomimo tego, że masa osób usiłowała zaprzeczać faktowi - tak samo nie miałem żadnej różnicy w FPS pomiędzy teksturami TGA i DDS. Była niewielka różnica w czasie ładowania, ale mało zauważalna.

Ergo nie tędy droga. MaSzyna zacinała mi z kolei po ustawieniu wszystkich efektów graficznych na minimum przykładowo na Drawinowie, na stacjach. Mogłem sobie nawet wygładzanie krawędzi wyłączyć i filtrowanie tekstur, tam klatkowało i koniec. Na każdej karcie graficznej tak samo, efekt klatkowania był zależny wyłącznie od CPU, w ogóle nie od karty graficznej.

FPS jest wyznacznikiem wydajności jedynie na monitorach CRT lub tych nowszych, które mają dynamiczną synchronizację ramki. Przy opcji vsync on FPS nie mówi nic. Nawet jak moja karta jest w stanie wyświetlić 300FPS, to i tak wyświetli 60 więc co mi mówi o wydajności FPS? Nic.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 12 Marca 2017, 08:11:10
@HTD, z całym szacunkiem ale wygadujesz rzeczy, które Ty doświadczyłeś. Moje doświadczenia, są zupełnie inne. Nic mi nie wyskakuje, jakość obrazu nie pogorszyła się. Ale to subiektywna ocena. Nie zgadzam się, że wprowadzenie dds nie miało wpływu na czas ładowania, bo to dziś jeszcze można udowodnić. Do tego tekstury TGA zajmują więcej miejsca w pamięci. Ponieważ zawsze pod ręką miałem kilka komputerów, to pozwolę sobie zaprzeczyć, że efekt klatkowania zależy tylko od procesora. Przytaczać przykładów nie będę, tu nie ma miejsca na takie dywagacje, chyba, że w osobnym wątku. O ile wiem, nie mamy możliwości zrobić rewolucji na posiadanym exe, materia jest delikatna i czasem doprowadza do płaczu i krwawienia oczu (cytata za tmj i milek7). Twoje pomysły można by zastosować w aplikacji od nowa pisanej, jeśli w ogóle coś wnoszą. Przejadę Drawinowo, wypowiem się na temat wyglądu lasów i wsi.
ED:
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. Niestety ogromne pogorszenie jakości obrazu i to wcale nie na stacjach, które wyglądają tak samo, tylko jadąc przez las i wieś, gdzie miałem zawsze 60FPS na starym exe.
Pogorszenie polega na wyskakiwaniu dużych elementów typu ściany lasu, budynki i grupy drzew przed kamerą. <ciach>
Nic mi nie wyskakiwało FPS od 65 na stacjach do 200 w trasie. Oczywiście uwolniony monitor od synchronizacji. Jak wiesz posiadam nie najnowszy sprzęt i z wyniku jestem bardzo zadowolony.
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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 12 Marca 2017, 12:02:53
U mnie ucina dźwięki syreny, dźwięk rozpoczynający i trwający jest, natomiast kończącego wcale nie odpala. Na exe 11.03 działa bez problemu.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 12 Marca 2017, 12:11:29
Jakbyś jeszcze loka podał, bo wiesz w siódemce, ósemce i dziewiątce mam ok.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Wiggle w 12 Marca 2017, 12:15:25
Traxx, kibel, na razie tylko odpaliłem i był ten sam błąd. U mnie na siódemce dźwięk się kończący odpala, ale nie trwa do końca, tylko go ucina, a w tych co wymieniłem wgl sie nie odpala.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 12 Marca 2017, 12:33:34
Sprawdziłem, tak jak pisałem 07, 08, 09 mam dobrze. Trax jest dziwny na 0311 i na 0312
Kibel jest ok na 0311, jest źle na 0312. Potwierdzam, że z dźwiękami Traxa i Kibla coś się zadziało.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 12 Marca 2017, 12:54:05
Pogorszenie polega na wyskakiwaniu dużych elementów typu ściany lasu, budynki i grupy drzew przed kamerą.
Sprawdz, jesli mozesz, czy to wystepowalo przy wersji 03.12, czy takze na poprzednich? Albo wylacz na chwile vsync in 03.12 i porownaj czy dalej jest to samo?

W 03.12 przy zmianach zgubilo sie dotychczasowe zachowanie domyslne symulatora, czyli zwiekszenie poczatkowego zakresu widzialnosci przy fps > ~30. Idzie do porawki, lacznie z przebazowaniem tego na czas kreslenia ramki, bo to sensowny pomysl.

edit:
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.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Siecool w 12 Marca 2017, 13:09:10
Do kolekcji. Sceneria ta sama, misja inna, szybko poszło, bo w mniej niż 10 minut.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 12 Marca 2017, 14:51:13
Zmiana zakresu na wielkie trójkąty nie pomogła. Gdy jest 3x to jest, spoko, ale jak mi fps spadł i zeszło do 1.4x to zaczęło być brzydko. Znacznie brzydziej niż wcześniej. Nie obcina rysowania całości. Teren w e3d był po horyzont, tory ucinało w widocznej odległości, dworca wyświetlało tylko niektóre elementy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 12 Marca 2017, 16:10:27
OK, czyli wyglada na to ze eksperyment sie nie powiodl, odlozymy to do czasu gdy teren zostanie ogolnie ogarniety. A na razie wracamy do tego co bylo, a wlasciwie czesciowo do tego co bylo (kod rysujacy) ale z regulacja zakresu na podstawie predkosci rysowania ramek, a nie fps.

Nawiasem mowiac, wyglada na to ze powrot do starego renderowania terenu naprawil tez uciete dzwieki syreny. Albo moze ja gluchy jestem, ale tak czy owak magia panie, magia.

A zeby nie bylo calkiem nudno, to symulator ma teraz swoja ikone na belce okna (glownego okna, nie tego do logowania) prawie jak prawdziwy program :d

edit:
Do kolekcji. Sceneria ta sama, misja inna, szybko poszło, bo w mniej niż 10 minut.
To chyba znowu brak pamieci jest, bo wylecial na bad_alloc() jak przedtem. Chociaz zawsze w tym samym miejscu, co jest dosc podejrzane. Troche trudno dojsc, czemu akurat tam, ale jesli uda mi sie wywolac to u siebie, to sie przyjrze.

Powtórzę pytanie o migotanie krawędzi przenikających się tekstur (przykład: trawa+podsypka, ale nie tylko bo są inne tekstury nakładane na trawę). Będzie można coś na to poradzić? Nie pytam z niecierpliwości, jestem zwyczajnie ciekawy.
Tutaj wplyw ma w duzej czesci ograniczenie 'rozdzielczosci' liczb zmiennoprzecinkowych, im dalej od "punktu 0" tym jest gorzej. Byc moze uda sie cos tutaj zrobic stosujac pewne sztuczki, ale zadnej gwarancji ze cos z nich wyjdzie niestety nie ma, zwlaszcza gdy kod rysujacy jest zakrecony tak jak jest. Sam chcialbym to poprawic, mnie tez to denerwuje ;d

edit2: aha, zapomnialem, poniewaz zgloszono zapotrzebowanie to ctrl + rolka kontroluje teraz przyblizenie takze w trybie normalnym, nie tylko debug.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 12 Marca 2017, 17:56:23
@tmj, dobra, usuwam poprzedni komentarz, odnoszący się do poprzedniej wersji.

PEŁEN SUKCES. Na 312b w Drawinowie mam cały czas 60FPS i nie ma "pustyni". Ideał! Rysowanie mam 1.5x na stacjach, poza stacjami 3x, czyli teraz działa to dokładnie tak jak powinno.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 12 Marca 2017, 18:07:37
Ktoś kiedyś pisał, że nie ma sensu, żeby kosz na śmieci był widoczny z 500m, racja. Ale ściana lasu to nie wiem, nawet z kilometra powinna się wyświetlać. Podobnie budynki i drzewa.
Zgadza sie, sek w tym ze symulator nie rozumie czegos takiego jak "kosz" czy "sciana lasu" -- dla niego to jest wszystko to samo, zbior trojkatow ktore kaze mu sie narysowac. A kiedy rysowac, to juz jest w duzym stopniu decyzja autora obiektu i/lub sceny, ktory ustawia parametry minimalnego i maksymalnego zakresu widocznosci. W przypadku scian lasow i innych tego typu konstrukcji problematyczne moze byc podejscie konstruowania tychze w oparciu o pojedyncze prostokaty kilometrowej i wiekszej dlugosci. Do pewnego stopnia exe sobie to podzieli na mniejsze kawalki, ale na pewno nie pomaga to w okresleniu, gdzie taki obiekt sie znajduje, i kiedy go wyswietlic.

Jesli mozesz, to sprawdz tez jak sytuacja wyglada w 03.12b -- klopoty w 03.12 do pewnego stopnia byly kombinacja wlaczonego vsync i zmienionej regulacji widocznosci, co spowodowalo ze widziales mniej wiecej to, co symulator zazwyczaj wyswietla przez pierwszy ulamek sekundy swojej pracy. W biezacym uaktualnieniu powinno to ulec poprawie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: youBy w 12 Marca 2017, 18:29:17
Jak coś, to w kodzie powinny się jeszcze pałętać resztki przesuwacza scenerii po przekroczeniu (chyba) 10 km od środka.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 12 Marca 2017, 18:31:29
Teraz jest idealnie w tej wersji. W poprzednich nie było przycinania, ale było klatkowanie. Teraz wilk syty i owca cała. Nie ma ani klatkowania ani przycinania. Jest super. Nie wiem jaką magią to osiągnąłeś, ale to mocne voodoo ;) A co do tej odległości od środka, czy to jest bug OpenGL, czy efekt jakiegoś innego problemu?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 12 Marca 2017, 18:34:36
Jak coś, to w kodzie powinny się jeszcze pałętać resztki przesuwacza scenerii po przekroczeniu (chyba) 10 km od środka.

Aha, jest tam cos takiego, ale wylaczone. Mysle raczej o zrobieniu tego dynamicznie, tzn zamiast bawic sie w ustawianie macierzy na pozycje kamery a potem przesuwac dodatkowo o wspolrzedne obiektu, mozna by sprobowac podejscia gdzie kamera jest zawsze traktowana jakby byla w punkcie 0, a obiekty sa jednynie przesuwane o roznice miedzy kamera a ich wlasna pozycja. Ale to moze wymagac zmiany tego, jak obecnie kalkulowane i przechowywane sa wspolrzedne, na sucho trudno powiedziec.

A co do tej odległości od środka, czy to jest bug OpenGL, czy efekt jakiegoś innego problemu?
To troche kombinacja czynnikow, ale oba sprowadzaja sie do tego, ze liczby typu float maja ograniczona precyzje -- im wiecej liczb po przecinku, tym mniej 'miesci sie' przed przecinkiem, i odwrotnie. Wiec przy obiektach o wspolrzednych kilku- lub kilkunastu tysiecy metrow, precyzja spada wrecz do centymetrow, i to co technicznie jest of siebie odsuniete, zaczyna sie pokrywac. Dodatkowo openGL (ale to nie jest tylko openGL) uzywa tych liczb do okreslenia na jakiej 'glebokosci' zostaly namalowane piksele, co jest uzywane przy decyzji ktore trojkaty zaslaniania inne. Podobnie wiec, wieksza precyzja blisko kamery skutkuje pogorszeniem dla obiektow odleglych. Mozna to troche kontrowac renderowaniem tzn osobno obiekty odlegle, osobno bliskie, albo kombinowaniem z tzw buforem logarytmicznym, ale to sa dodatkowe komplikacje.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 12 Marca 2017, 19:16:35
ztcp to depth buffer w opengl jest logarytmiczny
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 12 Marca 2017, 19:27:10
Nie dam glowy ze cos sie pod tym wzgledem nie zmienilo, ale do niedawna przynajmniej skalowanie bylo linearne + troche dodatkowego kombinowania*; gdyby bylo inaczej ludzie nie marnowali by wiele energii zeby temu zaradzic ;)  tutaj jest niezly artykul na ten temat: http://outerra.blogspot.com/2012/11/maximizing-depth-buffer-range-and.html

edit:
*) tutaj jest artykul o szczegolach, i fajny kalkulator ktory demonstruje jak zmienia sie rozdzielczosc w zaleznosci od parametrow bufora, i polozenia obiektu: https://www.sjbaker.org/steve/omniv/love_your_z_buffer.html
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 12 Marca 2017, 19:50:39
tak, masz rację. miałem tylko na myśli że nie jest całkowicie liniowy tylko wraz z oddalaniem się od znear precyzja maleje. (co właściwie ze względu na to że floaty też tak to jeszcze bardziej pogarsza sprawę przy dalszych obiektach)
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 13 Marca 2017, 07:37:35
Ktoś wie co tu się stało? Jechałem sobie dziś na nowym exe scenariusz calkowo_sn61, ale bez SN-61, z racji tego, że popsuta jest. Zamiast tego wziąłem stonkę. I niespodzianka - trasa nagle dostała działającego kierpocia, tak sama z siebie. Nigdy na tej trasie nie słyszałem kierpocia, chociaż ewidentnie sygnał odjazdu jest nagrany. Przez całą trasę rozkład jazdy się przewijał, pomimo tego, że nigdy mi się to nie zdarzało na tej trasie.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Stele w 13 Marca 2017, 10:16:33
Ale tam od jakichś dwóch lat powinien być kierpoć i przewijany rozkład. Robiłem to kiedyś razem z SKP. :D
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 13 Marca 2017, 11:39:05
Ktoś wie co tu się stało?
No to przejechałem na SN61 i też mi się przewija rozkład i mam kierpocia.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: HTD w 13 Marca 2017, 13:54:07
Ale na starym exe też? Bo mi na starym exe (wersja 482 bodajże) kierpoć nie działał. Później nie testowałem, dziś pierwszy raz odpaliłem to na nowym exe i kierpoć działał. Wyglądało to tak, jakby nowe exe miało poprawionego jakiegoś buga który psuł kierpocia. No albo to jakieś czary.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Krzysiek626 w 13 Marca 2017, 15:03:07
Nie sprawdzalem na exe z pacza, wydaje mi sie ze nie dzialalo. Bedzie chwila sprawdze, calej scn nie musze jechac.
ED:
Na exe 481 coś ze skanowaniem i tabelą jest nie tak, po zakończeniu manewrów w Jarkawkach, w tabeli nie ma stop_info. Nawet AI szamocze się, nie wie czy ma jechać czy stać. Myślę, że to już mało ważny szczegół jest.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 13 Marca 2017, 18:28:37
Sprawdziłem ten GL_POINT_SMOOTH i to nie to. Niestety camera frustum tutaj psuje. Myślę, ze wprowadziłeś dużo cache misses w tym kodzie i ograniczyło mocno wydajność.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 13 Marca 2017, 19:28:48
Sek w tym, ze frustum to jest zaledwie kilka przemnozen zwyklych macierzy 4x4 na ramke, i podobnie ograniczony wplyw przy kalkulacji widocznosci (kilka-kilkanascie mnozen, w porywach kilkadziesiat przy duzej ilosci pojazdow na ekranie) A symulator wykonuje takich operacji na ramke w tysiacach jesli nie dziesiatkach tysiecy, wiec 50% spadek wydajnosci ma tu bardzo malo sensu.

Przyszlo mi do glowy cos innego -- w tym uaktualnieniu eksperymentalnie jest tez wylaczony limit dla kalkulacji fizyki, tzn poprzednio liczone bylo maks. do 20 iteracji, a po zmianie liczy tyle, ile mu wyjdzie. Zastanawiam sie teraz, czy to nie powoduje roznicy przy slabszej wydajnosci, byloby to bardziej sensowne wytlumaczenie. Przywroce w nastepnym uaktualnieniu ugraniczenie i zobaczymy, czy cos sie zmieni.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 13 Marca 2017, 19:48:20
Ale robisz te dodatkowe obliczenia na danych, które masz aktualnie już użyte (więc są w cache) czy ciągniesz na nowo z ram-u? Jak to drugie to spadek wydajności masz gwarantowany.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 14 Marca 2017, 11:55:43
Przepuscilem exe przez profiler, i wychodzi ze potencjalnie zrodlem spowolnienia moze byc uzycie funkcji glGet do odczytu aktualnego ustawienia kamery; niektore implementacje/sterowniki nie lubia jej bardziej niz inne. Problem w tym, ze na chwile biezaca idealnego rozwiazania tutaj nie ma. Mozna:
- wrocic do tego co bylo, i ignorowac ze modele czasami znikaja kiedy nie powinny
- zostawic jak jest teraz i pogodzic sie ze na niektorych konfiguracjach bedzie wolniej
- wymienic odczyt na kalkulacje parametrow od strony exe. To akurat byloby najlepsze bo praktycznie calkowicie eliminuje koszt (w dodatku i tak trzeba to zrobic przy przejsciu na shadery itp) /ale/ latwo nie da sie zrobic, bo exe bardzo miesza przy renderowaniu widoku z kabiny, i dopoki sie tego nie rozsupla, zwykla wymiana wiecej psuje niz naprawia.

na razie sklaniam sie ku 2 i docelowo 3.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 14 Marca 2017, 12:02:23
Może glGet raz na ileś klatek (co sekundę?). Przez większą część czasu i tak się kamerą nie rusza specjalnie + zakres widoczności większy niż w rzeczywistości co powinno pomóc na delikatne ruchy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 14 Marca 2017, 12:41:11
Co sekunde to chyba raczej nie (trzeba by sie zaczac bawic w dodatkowe sprawdzanie czy nie bylo przelaczenia widoku np na lusterka itp) ale mozna by sprobowac uaktualniania co kilka klatek, zobaczymy.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: firleju w 14 Marca 2017, 13:29:03
No też wydaje mi się, że jeśli funkcja jest zasobożerna to lepiej jej nie uruchamiać za często.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 14 Marca 2017, 14:38:27
Przepuscilem exe przez profiler, i wychodzi ze potencjalnie zrodlem spowolnienia moze byc uzycie funkcji glGet do odczytu aktualnego ustawienia kamery; niektore implementacje/sterowniki nie lubia jej bardziej niz inne. Problem w tym, ze na chwile biezaca idealnego rozwiazania tutaj nie ma. Mozna:
- wrocic do tego co bylo, i ignorowac ze modele czasami znikaja kiedy nie powinny
- zostawic jak jest teraz i pogodzic sie ze na niektorych konfiguracjach bedzie wolniej
- wymienic odczyt na kalkulacje parametrow od strony exe. To akurat byloby najlepsze bo praktycznie calkowicie eliminuje koszt (w dodatku i tak trzeba to zrobic przy przejsciu na shadery itp) /ale/ latwo nie da sie zrobic, bo exe bardzo miesza przy renderowaniu widoku z kabiny, i dopoki sie tego nie rozsupla, zwykla wymiana wiecej psuje niz naprawia.

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

Shadery ostatnio podpiąłem eksperymentalnie do VBO (https://milek7.pl/.stuff/eu07scr/03-12/), tylko trzeba naprawić freespoty, uzyć współczynnika specular z obiektów, poprawić ustawienia świateł i ogólnie zrobić porządek. Póki co macierze też wyciągam z glGet przed rysowaniem i wpycham do uniformów, więc też przydało by się to poprawić skoro są problemy z wydajnością glGet. Jak ktoś chce mogę wrzucić ten kod co mam na githuba.
 
Ostatnio mam trochę innych rzeczy do roboty i będę mógł skończyć grzebanie w shaderach i zrobić stos macierzy na GLM dopiero pod koniec/w następnym tygodniu.
btw. tmj, nie wpadłbyś na irca?
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 14 Marca 2017, 14:54:35
Żeby nie rozgrzebywać kodu można by zachować stos macierzy, tylko napisać klasę z api takim samym jak w opengl i najlepiej użyć GLM do obliczeń.
Sek w tym ze rozgrzebac i tak chyba trzeba bedzie, bo tak jak zauwazyles, shaderom trzeba bedzie podawac macierze do rysowania, a w trybie kabinowym sa robione takie siupy z przesunieciami, rotacja itp ze --jak to mowia-- bez pol litra nie rozbieriosz. Wiec na dluzsza mete chyba lepiej to bedzie uproscic, bo bedzie wylazilo do konca zycia. Glm podpialem do tego recznego liczenia, ale wlasnie na trybie kabinowym polegl (w zewnetrznym jest prawidlowo) Tez sie zastanawialem nad zrobieniem takiego programowego stosu, to bedzie chyba najwygodniejsze podejscie.

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

Na ircu to tak chyba z 15 lat nie bylem, za leniwy jestem.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: Milek7 w 14 Marca 2017, 15:18:51
No bez rozgrzebywania to trzeba by zaimplementować glTranslate, glRotate, glScale, glMultMatrix, glPushMatrix, glPopMatrix, itp. i liczyć to sobie samemu w glm, przy każdej zmianie ustawić flagę dirty. Zwrappować glDrawArrays i jeżeli jest ustawione dirty to przepchać macierze do uniformów. Wtedy obeszło by się prawie bez zmian w obecnym kodzie.

Oczywiście przyszłościowo lepiej by było pozbyć się tego wrappera i przekazywać macierze na zwykłym stosie w argumentach metod, ale trzeba by wtedy rozgrzebać te kabiny i wszystko.
Tytuł: Odp: Odp: Exe - konwersja na C++
Wiadomość wysłana przez: tmj w 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

Ty