Pokaż wiadomości

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


Wiadomości - tmj

Strony: 1 ... 26 27 [28]
811
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 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.

812
Działa też release?
Tak, release jest ustawiony zeby tez generowac symbole tak samo jak debug, wiec wystarczy ze masz u siebie plik .pdb z kompilacji i debugger juz to sobie rozpracuje.

813
Zeby ulatwic troche wylapywanie tego typu "losowych" bledow, dodalem do .exe funkcje zgrywania tzw. crashdump, jesli zdazy mu sie pojsc w maliny. Bedzie to plik wielkosci ~300 kb z rozszerzeniem .dmp, w katalogu glownym. Wystarczy go dolaczyc tutaj do watku albo gdzie indziej, i Firleju albo ja albo kazdy inny zainteresowany moze toto sobie otworzyc w VS czy innym debugerze, i dostanie przynajmniej lokacje ktora wygenerowala blad, plus callstack. Co jest lepsze niz nic :)

Nie wiem czy dbghelp.dll jest instalowana domyslnie w systemie i czy nie bedzie potrzebna, wiec na wszelki wypadek dolaczam ja razem z .exe

814
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 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.

815
Na warsztacie / Odp: Planowane zmiany w exe
« dnia: 02 Lutego 2017, 18:28:59 »
Nazwalbym to moze raczej pociag->zespol->pojazd, bo na poziomie podstawowym niekoniecznie musi byc to wagon, ale tez np. lokomotywa, ale to kosmetyka ;) a samo podejscie wyglada sensownie.

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

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

816
Na warsztacie / Odp: Planowane zmiany w exe
« dnia: 01 Lutego 2017, 22:24:21 »
Dokleje tylko moj wczesniejszy kawalek z watku c++ zeby nie zginal

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

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

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

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

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

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

817
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 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

818
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 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 ;)

819
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 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.

820
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 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.

821
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 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 ;/

822
Bieżące Symulatorowe / Odp: Format mmd zgodny z YAML
« dnia: 28 Stycznia 2017, 02:52:48 »
Teraz juz wezmie, jesli trzeba -- dodalem "nowemu" parserowi ta umiejetnosc, tzn. jesli napotka cudzyslow, to wciaga wszystko co jest za nim, az do napotkania nastepnego cudzyslowu i traktuje to jako pojedynczy token. Ale zeby nie bylo za rozowo wymusza to ograniczenie parsera do pobierania symboli (przynajmniej tych tekstowych) pojedynczo, tzn
parser.getTokens(); parser >> token;
parser.getTokens(); parser >> token;

itd, co bedzie wymagac troche pogrzebania w kodzie w miejscach  gdzie czytanych jest teraz kilka symboli naraz. Na szczescie zbyt wiele ich chyba nie ma.

edit: w sumie szybciej wyszlo przerobic parser troche bardziej. Teraz obsluguje cudzyslowy, ale jest kompatybilny wstecz i nie wymaga gmerania w reszcie kodu. Lenistwo ftw.

823
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 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)

824
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 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

825
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 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 ;)

826
Pomoc doraźna / Odp: Dobór karty graficznej
« dnia: 21 Stycznia 2017, 03:07:35 »
Współczesne karty graficzne wymagają dodatkowego zasilania, które zasilacz musi dostarczyć.
To akurat zalezec bedzie od modelu -- np 750 TI (i uaktualnienie, 1050 TI) zadowalaja sie napieciem z szyny, bez zadnych dodatkowych wtyczek. 750 TI to prawdopodobnie bylby przyzwoity wybor do tej konfiguracji i zastosowan -- z symulatorem radzi sobie niezle, a ze wzgledu na wiek i target nie jest zbyt kosztowna.

827
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 19 Stycznia 2017, 22:10:05 »
Ja tez bylem kiedys mlody i mialem dobre oczy. ;d

828
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 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.


829
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 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)

Strony: 1 ... 26 27 [28]