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

782
Na warsztacie / Odp: Planowane zmiany w exe
« dnia: 01 Marca 2017, 04:55:08 »
A jak nie ma przycisku w kabinie to nie działa (por. piasecznica, przyp. redaktora). Tylko jak się w to już bawić to na docelowo. Powiedzmy, że pomysł ze sterowaniem tmj jest ok, tzn Train przechwytuje zdarzenie i rozsyła po wszystkich pojazdach. Każdy pojazd zmienia swój stan wewnętrzny na podstawie właściwości (prowadzący, ukrotniony czy co tam jeszcze) i przesyła dane do wszystkich instancji kabin. Te sobie ustawiają na podstawie stanu odpowiednie urządzenia (wtedy w kabinie B będą się załączały lampki przy sterowaniu w kabinie A). Wtedy brak przycisku po prostu nic nie animuje, ale sam stan pojazdu się zmieni.
Tzn. mozna to zrobic tak, a jakby ktos sie uparl zeby bylo bardziej "prawdziwie" to mozna aranzowac w ten sposob, ze na pewnym poziomie sa urzadzenia wejscia (interpreter klawiatury, konsoli, joysticka, klikania na element w kabinie, AI mechanic czy co tam jeszcze) i te przekladaja otrzymane od uzytkownika sygnaly na instrukcje uniwersalne typu "nastawnik raz do przodu", ktore sa przesylane do klasy-posrednika. A na drugim poziomie masz obiekt - odpowiednik konsoli sterowania w lokomotywie, ktory sie u tego posrednika subskrybuje, ze chce otrzymywac konkretne instrukcje zgodne z tym, w co dana konsola jest wyposazona. I po otrzymaniu takich instrukcji konsola uaktualnia sobie swoj stan, i przekazuje instrukcje do pociagu, ktory juz ja sobie wykonuje/rozsyla dalej itp. Ta metoda mozna troche prosciej realizowac warianty typu dwie konsole w jednej kabinie, czy co tam jeszcze wyskoczy.

Do pewnego stopnia ten model juz jest, tylko zapackany przez dorzucone modyfikacje o shift, ctrl itp, ktore powinny byc zamiast tego osobnymi, pelnoprawnymi instrukcjami

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

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




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

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

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

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

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

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

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

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

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

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

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

796
Na warsztacie / Odp: Planowane zmiany w exe
« dnia: 17 Lutego 2017, 16:44:14 »
Starter by sie przydal, bo poleganie na zewnetrznych narzedziach nie jest specjalnie profesjonalne ;)  To raczej projekt na dluzsza mete, miedzy innymi dlatego, ze przydaloby sie do niego jakies UI, a tego w exe na razie ani sladu. UI ewentualnie bedzie musialo sie zjawic przy wprowadzaniu edycji scenerii z poziomu exe, wiec starter tez prawdopodobnie moze zmaterializowac sie wtedy.

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


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

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


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

801
Na warsztacie / Odp: Planowane zmiany w exe
« dnia: 11 Lutego 2017, 23:38:55 »
Opensourcowa implementacja openal wygląda na dosyć żywą: https://github.com/kcat/openal-soft
Nie ma tez specjalnie w czym wybierac jesli chodzi o alternatywy. Tzn. jest WWise, ktory jest uzywany znacznie szerzej i rowniez cross-platform, ale darmowa licencja ma dosc ostre ograniczenia. Druga opcja bylby prawdopodobnie FMOD, ale tutaj tez ewentualnie moga pojawic sie ograniczenia.

edit:
@tmj: no ale po co Ci elastyczny wrapper który zajmuje się tylko przekazywaniem danych dalej. Ponadto wagony skrajne w zespole muszę mieć wskaźniki na wagony skrajne w innych zespołach, gdyż inaczej nie policzysz hamulców oraz sił na sprzęgach. Oczywiście można inaczej zorganizować dane, żeby nie było wskaźników bezpośrednio do pojazdów tylko do potrzebnych danych, ale wtedy te dane trzeba trzymać na poziomie pociągu a nie zespołu (co nie znaczy, że pociąg ma robić z nimi cokolwiek poza trzymaniem).
Chcialbym go wprowadzic glownie po to, zeby zredukowac obecne klasy-monolity do bardziej sensownych rozmiarow. Takie rzeczy jak przekazanie sil/napiec/polaczen do sasiednich zespolow to jest wlasnie cos, co jak najbardziej mogloby sie znalezc w zespole, bo pociagowi to na nic, wiec nie ma powodu zeby tam to wpychac, a i pojazd/modul nie musi takich rzeczy robic osobiscie wiec po wyjeciu ich staje sie lzejszy. Na dluzsza mete ulatwiloby to tez synchronizacje wymiany danych miedzy elementami ktore licza fizyke, co moze sie przydac przy przejsciu na model wielowatkowy z obecnego 'kazdy wagon po kolei jeden po drugim'.
Masz calkowita racje co do rozpisania tego dokladniej, trzeba by nad tym pomyslec.

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


803
Na warsztacie / Odp: Planowane zmiany w exe
« dnia: 10 Lutego 2017, 13:46:49 »
Tylko, że jeśli klasa zespół ma być obecna dla każdego rodzaju pojazdu, to czym będzie się zajmować w przypadku wagonów towarowych, gdzie co najwyżej używasz hamulca? Rozsyłaniem komend do zespołów zajmuje się pociąg.
No zajmowala by sie tym samym, czym zajmuje sie dla zespolow wiecej niz jednego pojazdu -- w tym konkretnym scenariuszu kolejkowaniem i przesylaniem komend do kolejnego zespolu, na podstawie typu sprzegu miedzy nimi (to nie jest imo robota pociagu, pociag wydaje komende raz i szczegoly rozsylania go nie obchodza) jak rowniez, tam gdzie ma to sens, przekazywaniem ich 'w dol' czyli do indywidualnych pojazdow (w tym wypadku jednego pojazdu)

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

804
Na warsztacie / Odp: Planowane zmiany w exe
« dnia: 09 Lutego 2017, 11:26:36 »
Mnie chodzi to, żeby nie powstała sytuacja w której masz taki układ:
(..)
Czym to się różni w architekturze od obecnego:
(..)[/code]
itd.
Akurat ta sytuacja nie rozni sie wiele, przynajmniej w tym ujeciu. Roznice wystepuja, gdy masz aranzacje np
Train->
    dynamic, en57a
    dynamic, en57s
    dynamic, en57b
    dynamic, en57a
    dynamic, en57s
    dynamic, en57b
bo taki uklad widziany jest wtedy jako
pociag->
    zespol->
        pojazd, en57a
        pojazd, en57s
        pojazd, en57b
    zespol->
        pojazd, en57a
        pojazd, en57s
        pojazd, en57b
Nie sa to byc moze sytuacje czeste, niemniej wystepuja, podobnie jak lokomotywy uokrotnione itp, wiec mysle ze warto miec taki uklad, ktory pozwala na ich obsluge bez wymuszania na pociagu babrania sie z indywidualnymi elementami, i sprawdzania czy sa one pojedyncze, czy w jakis sposob laczone.

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

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

806
Na warsztacie / Odp: Planowane zmiany w exe
« dnia: 07 Lutego 2017, 23:00:03 »
Całe clue zabawy polega na prawidłowym policzeniu odległości do obiektu podczas skanowania z czym aktualnie walczę.
Z tego co pamietam, zarowno sklad jak i eventy maja zdefiniowane absolutne wspolrzedne 3d, czy nie sprowadza sie to wiec po prostu do stworzenia wektora miedzy tymi dwoma punktami, i policzenia dlugosci? Czyli cos jak distance = vector3( vehicle.position, event.position ).length().

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

Cytuj
Co do pojazdów z fizyką, to zważ że jeśli zmiksujesz DynamicObject z TMoverParameters ze stworzeniem tego dla każdej klasy pojazdu osobno to w przypadku jeśli zawsze pociąg będzie zawierał zespoły i te dopiero pojazdy to dla typowego składu cargo sytuacja nie rożni się od obecnej.
Roznice pojawilyby sie na poziomie interakcji kontrolera ze skladem; w chwili obecnej to jest jedna wielka kupa instrukcji warunkowych -- jesli silnik typu x to zrob to, a jak y to tamto, a jak lokomotywa jest okreslonego typu.. itd. Po zmianach to wszystko byloby rozdzielone do konkretnych typow pojazdow, a obsluga zblizona do tego, co w tej chwili oferuje uklad hamulcowy. W pewnym sensie uklad zespol->pojazd(y) bylby analogiczny do biezacego ukladu pojazd->hamulec, tylko o poziom wyzej.

807
Na warsztacie / Odp: Planowane zmiany w exe
« dnia: 06 Lutego 2017, 15:24:19 »
Chciałbyś umieścić fizykę w klasie pojazdu?
No raczej tak, bo w zasadzie wszelkie kalkulacje trzeba bedzie przeprowadzac na poziomie poszczegolnych czlonow/wagonow/whatever. Gdyby sie strasznie chcialo, to mozna wydzielic z tego wozek jako sub-component, i np. prowadzic wozki po torze indywidualnie, i na podstawie tego kalkulowac, gdzie jest pudlo (dopoki sie nie rozerwie jak na rozjezdzie kazdy wozek pojdzie sobie na inny tor) Ale to tak opcjonalnie.

Cytuj
Chciałbym uniknąć niepotrzebnego tworzenia klasy zespół dla pojedynczych pojazdów. Tak naprawdę zespół jest potrzebny tylko do ezt. Cała reszta tego nie potrzebuje.
Ja bym to potraktowal troche bardziej ogolnie -- z punktu widzenia pociagu wszystko, co ma pod soba to zespoly, a juz tylko sam zespol obchodzi ile ma w sobie komponentow, i jakie. Tzn. mozna by sie tez alternatywnie bawic w aranzacje typu pociag -> pojazd, a dla pojazdow wyprowadzamy osobno zespol wariant, ale tego typu dziedziczenie na dluzsza mete bardziej chyba komplikuje sprawe, niz ulatwia.

Cytuj
Teraz eventy. Ogólnie mamy konsensus, że trzeba to wywalić, ale na potrzeby aktualnych prac myślałem nad tym jak AI współpracuje z modelem scenerii. Wpływ na prowadzenie postrzeganie trasy mają dwie rzeczy: tory oraz wszelakiego typu wskaźniki i semafory. Obecnie AI skanuje tor przed sobą i czyta czy jest do niego przypisany event od strony od której nadjeżdża. Potem event jest sprawdzany na okoliczność uznania go za "pasywny". Do tego punktu wszystko jest ok. Następnie wszystko jest wrzucane do wspólnego worka pod nazwą SpeedTable, która ma własne algorytmy przeliczania odległości od obiektów. Niestety, te algorytmy działają tylko przy założeniu, że urządzenia są przypisane do torów przy których stoją i w kolejności w jakiej stoją. Wszelkie błędy powodują nieprawidłowe przeliczanie odległości.
cdn..
Tutaj zastanawialem sie, czy sprawy nie uproscilo by faktyczne zalozenie, ze zrodla komunikatow sa wszystkie przypisywane do konkretnych torow. Tzn masz cos w rodzaju: uklad torow dzielimy na wierzcholki (semafory) i krawedzie (odcinki torow od jednego wierzcholka do drugiego), plus trzeci element jakim jest 'skrzyzowanie' czyli krawedz laczaca kilka wierzcholkow na specjalizowanych zasadach, uzywana do realizowania zwrotnic, obrotnic, skrzyzowan drog itp.  Bazujac na tym, zrodlo komunikatow jest traktowane jako punkt w danej odleglosci od konca/poczatku odcinka toru -- moze ich byc wiecej nie jeden, i tor trzyma sobie (posortowana) liste takich punktow wewnetrznie, i przekazuje zainteresowanym pociagom. W tym momencie odpada caly problem skanowania, bo po takim przekazaniu pociag wie dokladnie w jakiej odleglosci znajduja sie najblizsze komunikaty, i uaktualnia sobie te odleglosci po prostu na podstawie przejechanego dystansu.

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

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

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

810
Po ostatnich poprawkach do nowego .exe ET22-1008 prowadzony przez autopilota przekulal sie profesjonalnie cala droge do Ostrowa, stajac na W4 wg rozkladu. Pozostale pociagi na trasie tez wygladaly, jakby robily to co trzeba.

Strony: 1 ... 25 26 [27] 28