Otrzymane polubienia

661

Bieżące Symulatorowe / Odp: Podmiana obrazków z ekranu ładowania

« dnia: 06 Lipca 2017, 20:22:33 »

Wydaje mi sie, ze prostszym rozwiazaniem na ta chwile bylaby modyfikacja startera, bo jest teoretycznie minimalna -- zamiast 'zaladuj jpg, zeskaluj i zapisz jako bmp" robi sie 'zaladuj jpg, zapisz jako bmp'. Moze wiec uda sie namowic Ra?
Ladowanie .jpg moze sie ewentualnie znalezc w exe po podpieciu middleware do interfejsu uzytkownika, ale to jeszcze nie teraz zaraz juz.

edit: przy okazji, jak juz rozmawiamy o modyfikacjach startera, nie daloby sie wprowadzic drobnej zmiany by 'plik tymczasowy' zamiast zawsze nazywac sie $.scn mial forme $pierwotnanazwascenerii.scn czyli np $td.scn $drawinowo.scn itd? Raz, ze w ten sposob latwo moglibysmy miec nazwe scenerii w czasie ladowania takze przy zalaczonym pliku tymczasowym, a dwa ze dzieki temu modyfikacje moglyby byc robione dla kazdej scenerii indywidualnie, i nie gubilyby sie przy kazdym uruchomieniu nowego scenariusza, co jest chyba korzystne.

1 Lubię to

662

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« dnia: 01 Lipca 2017, 23:33:29 »

Próbowałem już różne kombinacje, m. in. tak, ale nie mogę trafić.

Kod: [Zaznacz]

glm::vec3 transdiff = glm::vec3(worldcamera[3]) - glm::vec3(depthcam[3]);
glm::mat3 rotdiff = glm::mat3(worldcamera) * glm::mat3(depthcam);
glm::mat4 lv = depthproj * glm::translate(glm::mat4(rotdiff), transdiff);


O ile dobrze pamietam to roznica obrotow dwoch macierzy to R1^-1 * R2, czyli na jednej z nich musi byc zrobiony inverse. Zwykle mnozenie da sume obrotow, nie roznice.

A co z opóźnieniem wyłącznika szybkiego? Dałoby radę coś zrobić?

Teoretycznie mozna, ale jesli w praktyce wyglada to tak, jak mowi @AtapiCl to nie wiem czy warto ;o

W dzisiejszym uaktualnieniu:

- eksperymentalnie, wrzucanie tekstur do karty graficznej wykonywane jest dopiero gdy tekstura jest potrzebna do narysowania sceny, a tekstury przez dluzszy czas nie uzywane przenoszone sa do czasu ponownego uzycia do pamieci zasadniczej. Efektem pozytywnym jest zmniejszenie uzycia pamieci vram, wiec jest szansa ze nie zabraknie jej zbyt szybko na wyswietlanie modeli. Efektem niepozytywnym natomiast moze byc okazjonalne przyciecie w renderowaniu, w czasie gdy dane tekstur przesylane sa miedzy karta i pamiecia zasadnicza (aby to wyeliminowac przydalaby sie obsluga tekstur na osobnym watku, ale tak dobrze jeszcze nie jest)

1 Lubię to

663

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« dnia: 01 Lipca 2017, 14:08:10 »

No niestety, jesli zabraknie pamieci na dane obiektow 3d to exe nie urodzi ;o Zastanawiam sie, czy nie warto by wprowadzic takze usuwania z pamieci karty graficznej nieuzywanych tekstur (po ujednoliceniu kodu jest to calkiem mozliwe) ale trzeba by tutaj troche poeksperymentowac.

1 Lubię to

664

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« dnia: 01 Lipca 2017, 12:01:34 »

Na zimno, UFO nadal jest. W załączniku widać jak otacza ET22 i jest tak na każdym modelu tej lokomotywy. Obraz zarejestrowałem po wyjściu z kabiny w debug mode kursorami na dość sporą jak widać odległość. Ta bańka podąża za lokomotywą nie odstępując jej na krok. Fatamorgana przesuwa się nieco obok loka, jeśli z kabiny wyskoczymy za pomocą F4.

Ta banka pojawia sie tylko gdy zalaczony jest debug mode, podejrzewam ze to sa wywolania funkcji zaznaczajacych pozycje ksiezyca i slonca (funkcje render() w cSun/cMoon) gryzace sie z aktywnym shaderem, albo cos w tym stylu.

Można wiedzieć, czym się objawiał?

Na niektorych zaokraglonych powierzchniach (grzybki w kabinie itp) mogly pojawic sie dosc wyrazne roznice cieniowania sasiednich trojkatow.

1 Lubię to

665

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« dnia: 30 Czerwca 2017, 23:19:25 »

Nie, u mnie tez to jest xD  w texture_manager::bind() jest blad, zamiast zapamietywac ostatnio ustawiony handle zapamietuje id tekstury powiazanej z handle, i w skrocie porownuje dwie rozne rzeczy decydujac czy nalezy zmienic teksture, czy nie. Wylazi to tylko wtedy gdy id i handle maja rozne wartosci, co sie z reguly nie zdarza. @AtapiCL mial to kiedys u siebie dzieki programowi overlay, to jest taka powtorka z rozrywki :>

zmien linie 818 w texture.cpp na

Kod: [Zaznacz]

m_activetexture = Texture;
i bedzie dobrze.

1 Lubię to

666

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« dnia: 30 Czerwca 2017, 21:21:01 »

Zgloszenie "niektore submodele" jest mniej wiecej tak samo przydatne jak stwierdzenie "cos jest nie tak" ;/

Wsliznal sie glupi blad przy kalkulacji wektorow normalnych dla wierzcholkow, w tej wersji powinno byc juz dobrze. Oprocz tego dodane przy okazji:

- obsluga dodatkowych typow przyciskow, pantselected_sw: i pantselectedoff_sw: podnoszacych/opuszczajacych pantografy wybrane przy pomocy odrebnego przelacznika/zaworu. Wspomniany odrebny przelacznik nie jest jeszcze zaimplementowany, tymczasowo obsluga kabiny z nowym typem przyciskow odbywa sie uzywajac standardowych kombinacji klawiszy obslugi pantografow.

1 Lubię to

667

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« dnia: 27 Czerwca 2017, 03:18:42 »

Dorzucilem na wszelki wypadek do exe rozpoznawanie tagu models: "wzbogaconego" o BOM utf8. Jesli sama zawartosc pliku jest w zwyklym ascii to powinno wystarczyc, a odpadnie koniecznosc sprawdzania i/lub poprawiania x plikow.

1 Lubię to

668

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« dnia: 26 Czerwca 2017, 15:36:22 »

Co ciekawe, bo tu usiadłem ze zdumienia, na intelu I5 12Gb ram i NV720 z WIN10, Kaliska wczytała się w ciągu 2,5 minuty.

Ale to w sensie ze zle czy dobrze :o  bo u mnie Kaliska wczytuje sie 90-120 sekund, w zaleznosci czy to start "na zimno" czy kolejne wczytanie.

Przy wyjsciu z kabiny przez F4 przestawienie kamery na zewnatrz dziala, bo jest obslugiwane przez inna czesc kodu. Tutaj akurat imo jest to korzystne, bo czesto pauza jest wykorzystywana podczas chodzenia po scenerii, i to chyba nie powinno byc blokowane.

2 Polubienia

669

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« dnia: 26 Czerwca 2017, 14:26:57 »

Nie ruszalem na razie, bo to jest raczej trzeciorzedny problem (bierze sie z tego ze ruch kamery w kabinie jest realizowany ze stalym krokiem, by utrzymac ten sam poziom rzucania kamera niezaleznie od FPS, i przy wlaczonej pauzie aktualizacja pozycji kamery nie nastepuje) Zrobie gdy mnie to dostatecznie zirytuje, albo nie bedzie nic pilniejszego na talerzu :d

1 Lubię to

670

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« dnia: 26 Czerwca 2017, 13:51:34 »

Witam. Ja zauważyłem coś innego. Od kiedy pojawiła się możliwość rozdzielenia trąbek na dwa osobne klawisze blokuje się dźwięk syreny pod kiedy jesteśmy zmuszeni zaraz po podaniu RP1 użyć piasecznicy. Dźwięk można zatrzymać ponownie wciskając s. Druga rzecz, nie wszędzie powinna być uruchomiona opcja rozdzielonej syreny. Z tego co wiem, to taka możliwość na pewno występuje na jednostkach EN57, EN71, ED72. Na lokomotywach EU07, ET22 i innych mamy wajchę, która coś takiego uniemożliwia. Uważam, że dobrze by było rozdzielić to jakoś, na przykład w pliku .fiz danego pojazdu w sekcji switches. Jeszcze jedno. W lokomotywie EP09 niema czegoś takiego jak kurek truj drogowy, więc opcja przestawiania tego kurka powinna być nieaktywna.

Blokowanie dzwieku ma miejsce ze wzgledu na to, jak system operacyjny przekazuje wcisniecia i zwolnienie klawiszy do aplikacji, miedzy innymi dlatego poprzednio bylo tutaj stosowane wymuszone wylaczenie jednego dzwieku przy aktywacji drugiego. Na ta chwile nie ma mozliwosci definiowania elementow wyposazenia takich jak typ przelacznika dzwieku, lub obecnosc zaworu trojdrogowego. Po wprowadzeniu ich bedzie mozna pomyslec o lepszym dopasowaniu konfiguracji do konkretnych typow pojazdow.

W dzisiejszym uaktualnieniu:

- poprawka, eksportowanie modeli do format e3d nie powinno sie juz rozsypywac w przypadku wystapienia w modelu nieprawidlowych trojkatow

- pseudo-poprawka, symulator powinien (w wiekszosci przypadkow) pracowac od poczatku z normalna predkoscia

- w ramach dyskusji w watku o wymianie ekranow ladowania, oprocz dotychczasowych ekranow z kwadratowych tekstur symulator przyjmuje takze ekrany nieprostokatne. Ekrany skalowane sa do wysokosci okna program, widocznosc (lub nie) bocznych krawedzi zalezy od stosunku proporcji ilustracji do proporcji okna symulatora.

1 Lubię to

671

Pomoc w tworzeniu / Odp: Usprawnianie starego taboru

« dnia: 25 Czerwca 2017, 21:48:25 »

Spuszczenie powietrza jest we wpisie w .scn, po kropce w wartosci sprzegu, np

node -1 0 ET42-025-A dynamic PKP\ET42_V2 112E-025-A 112E-A 0 headdriver 191.BQ 0 enddynamic
node -1 0 ET42-05-B dynamic PKP\ET42_V2 112E-025-B 112E-B 0 nobody 3.BQ 0 enddynamic

wyssie powietrze z obu czlonow.

1 Lubię to

672

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« dnia: 19 Czerwca 2017, 14:22:08 »

Grubosc przesla jest jednolita (tyle samo pikseli) na calej dlugosci, wiec uwzgledniajac perspektywe mozg interpretuje to jako zwiekszenie grubosci dla fragmentow polozonych dalej, zwlaszcza ze druty tam zbiegaja sie i to co wczesniej dosc wyraznie widac jako kilka indywidualnych przewodow zaczyna wygladac jak jeden grubszy kabel.

1 Lubię to

673

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« dnia: 17 Czerwca 2017, 14:39:55 »

Poprawiłem Opacity na 0, dalej nie ma szkiełek - np. models/pkp/sk12krat.t3d

Dziwne, u mnie po ustawieniu Opacity 0 pojawily sie. Nie masz przypadkiem ciagle w katalogu starego pliku .e3d? Jesli tak, to exe bedzie go ladowac, ignorujac poprawiony t3d.

1 Lubię to

674

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« dnia: 13 Czerwca 2017, 17:07:57 »

No przecież opisałem i dałem screena z wczytania pliku t3d na nowym exe i jest źle.

Krzysiu, ale mi chodzilo o to, czy zle bedzie takze przy ladowaniu t3d dla SU45, nie SP45 :) z tego co pisze @Maciej to nie, wiec byc moze rzeczywiscie jakas roznica miedzy tymi dwoma .t3d jest.

1 Lubię to

675

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« dnia: 05 Czerwca 2017, 01:44:09 »

W duzym skrocie tego typu defragmentacja to objaw, ze  karta graficzna i/lub system nie moze dostarczyc tyle pamieci, ile by chcial symulator. Na ten moment trudno powiedziec czy jest to blad gdzies w kodzie exe, czy tez ograniczenie windows XP -- poniewaz np @Krzysiek626 mial ten sam problem, ale jesli dobrze pamietam, to ustapil on po uruchomieniu symulatora na tym samym sprzecie, ale przy zainstalowanej nowszej wersji windows.

Kod graficzny exe przechodzi teraz pewne przerobki, wiec jesli blad byl po stronie exe to moze cos sie pod tym wzgledem poprawi, na razie jest jeszcze za wczesnie by mozna bylo powiedziec cos konkretniejszego.

1 Lubię to

676

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« dnia: 02 Czerwca 2017, 02:01:05 »

W dzisiejszym wczorajszym uaktualnieniu:

- eksperymentalnie, poprawki w sortowaniu i ogolnie obsludze dodawania eventow do listy; pisze "eksperymentalnie" bo nie ma pewnosci czy zmiana zachowania na takie, jakie powinno byc ale wskutek bledow nie bylo, nie wywola jakichs bledow w scenariuszach. Ale jak to mowia, jest tylko jeden sposob zeby sie przekonac.

edit: w ramach dalszych eksperymentow

- rozdzielone dzialanie przyciskow kontroli syreny, aktywacja tonu wysokiego nie wylacza niskiego, i odwrotnie. Aby uniknac blednego zapetlania sie dzwiekow aktywacja tonu wysokiego zostala przeniesiona domyslnie pod klawisz S (kontrola piasecznicy jest teraz domyslnie pod shift+S, a przelacznik blokady drzwi pod ctrl+S)

aktualne zrodla ida na githuba, wiec mozna je podlaczac do czego tam kto chce :d

1 Lubię to

677

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« dnia: 28 Maja 2017, 22:05:40 »

Myslalem raczej o daniu A i S dla tonow, a ewentualnie uzyciu Z dla trzeciego tonu, dla lokomotyw ktore maja dodatkowy sygnal. Tak czy owak zapewne znajdzie sie to w ktoryms uaktualnieniu do przetestowania.

Co do opoznienia, faktycznie moze miec miejsce gdyz odczyt klawiatury opiera sie teraz na komunikatach przekazywanych przez system operacyjny, zamiast bezposredniego odczytu stanu klawiszy. U siebie opoznienie powtarzania mam zredukowane do minimum, wiec nie rzucilo mi sie w oczy, bo w tym ustawieniu roznica opoznienia miedzy pierwszym i powtorzonymi wcisnieciami jest minimalna, o ile w ogole wystepuje.

1 Lubię to

678

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« dnia: 28 Maja 2017, 20:16:02 »

To może warto się zastanowić nad tymi syrenami, gdyż moim zdaniem brak "płynnego" przejścia między tonami negatywnie wpływa na odzwierciedlenie rzeczywistości.

W rzeczywistosci w duzej liczbie lokomotyw ktore mamy w symulatorze syrena jest zalaczana dzwignia ktora ma jeden dzwiek na koncu wychylenia w jedna strone a drugi dzwiek na koncu wychylenia w druga strone. Fizycznie nie ma w takim ukladzie mozliwosci zalaczenia obu tonow naraz -- dzwignia umozliwia tylko albo-albo. Zas "plynne przejscie" w takim ukladzie wymaga przesuniecia dzwigni z pozycji A do pozycji neutralnej, a nastepnie do B.

Ja rozumiem ze komus moze byc latwiej przycisnac sam shift niz na ulamek sekundy podniesc wczesniej palec z klawisza i przylozyc go z powrotem, ale odzwierciedlania rzeczywistosci w to nie wplatujmy, bo z nia akurat ma to zero wspolnego. Dlatego miedzy innymi wydaje mi sie, ze zmiana domyslnych klawiszy tak zeby nie bylo miedzy nimi 'punktu wspolnego' bylaby tu sensowna.

(co do dzwieku wydawanego przy przelaczaniu to jest placeholder, bo na razie nie ma w exe przypisywania indywidualnych dzwiekow do poszczegolnych przelacznikow)

1 Lubię to

679

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« dnia: 26 Maja 2017, 23:23:04 »

Sprawdzilem, wychodzi ze ten dzwiek to byl zapetlony start/stop dzwieku wpadania w poslizg, ktory bral sie z blednej kalkulacji -- sila hamowania 'zaciagnietych' hamulcow stojacego pojazdu przekraczala przyczepnosc, i w efekcie bez przerwy wpadal on w poslizg i 'wychodzil' z niego.
Ten sam efekt dotyczyl tez samochodow, ale kiedy go wczesniej zauwazylem odlozylem go do sprawdzenia na pozniej. 'Pozniej' przyszlo teraz, poprawka bedzie w nastepnym uaktualnieniu.

Czy jesteśmy jakoś zabezpieczeni w exe przed taką dwoistą informacją? Gdyby coś, to skanowanie pokazuje seminfo 0km/h, a na semaforze mamy co widać.

W normalnych warunkach uaktualnienie stanu semafora powinno nastapic po krotkim czasie (1-2 sek) od zmiany sygnalu.

1 Lubię to

680

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« dnia: 25 Maja 2017, 20:44:47 »

W dzisiejszym uaktualnieniu tylko jedna zmiana, natomiast, ze sie tak wyraze, jakosciowa :d

- zmiana w systemie wizualizacji -- jest ona teraz oparta na biezacej pozycji kamery, co w praktyce oznacza ze rendering ma praktycznie ta sama precyzje w kazdym punkcie mapy. Tym samym powinno zostac w wiekszosci wyeliminowany z-fighting i drgania (poza tymi, ktore biora sie z rzucania pudlem pojazdu

(tutaj uwaga, pod system nie jest (jeszcze) wlaczony teren z pliku .e3d wiec jesli scena wykorzystuje ten typ terenu, to z-fighting z podsypkami torow do pewnego stopnia bedzie ciagle obecny. Na sceneriach nie uzywajacych tego terenu powinno byc juz calkiem przyzwoicie)

5 Polubienia

681

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« dnia: 22 Maja 2017, 18:37:09 »

Tmj tak jak ci pisalem. Przelacznik jest czynny tylko na sekcji na ktorej jedziemy. Chodzi o to ze mech moze wylaczyc sprezarke i przeywornice na sekcji na ktorej jedzie. Chodzi o halas. To sa dedykowane hebelki. W tylnej sekcji zawsze dziala.  Prosze tez o wylacznik rozrzadu i stycz liniowych.

Wylacznika rozrzadu raczej na razie nie bedzie, bo nie ma w exe mechanizmow w ktore moznaby go wpiac (indywidualnie zapamietywany stan urzadzen dla poszczegolnych pulpitow/kabin, czy chocby obecnosc w pamieci wiecej niz jednej kabiny naraz) Bedzie musiala wystarczyc reszta:

- poprawka, wylacznik stycznikow liniowych w lokomotywach dwuczlonowych (ET41, 42) wplywa na stan obu czlonow zamiast tylko obsadzonego

- wylacznik stycznikow liniowych moze byc obslugiwany jako bistabilny, a nie tylko impulsowy jak dotychczas. Tryb bistabilny ustawia sie wpisem w pliku .fiz w sekcji Switches:

Kod: [Zaznacz]

MotorConnectors=Toggle
przy braku wpisu przelacznik jest traktowany domyslnie jako impulsowy

- dodana obsluga przelacznikow przetwornicy i sprezarki, dzialajacych selektywnie dla obsadzonego czlonu. Kontrolowane domyslnie przez Shift-X (przetwornica) i Shift-X (sprezarka) Nazwy przyciskow w pliku .mmd to

Kod: [Zaznacz]

converterlocal_sw
compressorlocal_sw


1 Lubię to

682

Na warsztacie / Odp: Metro bałtyckie

« dnia: 21 Maja 2017, 18:59:28 »

Szukałem i próbowałem dość długo znaleźć optymalne ustawienia, niestety na exe++ bardzo ciężko ustawić pogodę. Przydatne byłoby ustawienie: niebo statyczne, słońce w zenicie, zachmurzenie całkowite.

Slonce w zenicie: ustaw parametr movelight (czyli dany dzien roku) na wartosc miedzy 160-180 czyli lato, a godzine na 12:00 czy cos kolo tego, slonce jest wtedy najwyzej. Calkiem pionowo nie bedzie, Polska to nie Afryka.
Niebo statyczne przypisujesz tak jak na exe borlandowym, wstawiajac odpowiedni model .t3d we wpisie sky  Jesli bedzie to tekstura w pelni zachmurzonego nieba, to bedziesz mial statyczne w pelni zachmurzone niebo.

1 Lubię to

683

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« dnia: 20 Maja 2017, 21:01:54 »

W dzisiejszym uaktualnieniu:

- korekta zalaczania sprezarki dla lokomotyw dwuczlonowych (ET41, 42): sprezarki zalaczaja sie tylko gdy moga uruchomic sie razem, tzn zadna nie jest blokowana przez wylacznik cisnieniowy (do pewnego stopnia jest to tylko proteza, bo nie obejmuje zachowania innych kombinacji ukrotnienia itp, ale na razie lepsza nic nic)

- korekta logiki wykrywania czy lokomotywa jedzie 'pusta' i powinna uzywac hamulca lokomotywy a nie glownego, dotyczylo lokomotyw dwuczlonowych (ET41, 42)

- dodany przelacznik w pliku .ini, input.gamepad kontrolujacy czy exe ma obslugiwac gamepad/joystick. Domyslnie zalaczone, moza wylaczyc poprzez wpis

Kod: [Zaznacz]

input.gamepad no
powinno pomoc w przypadku konfiguracji z podlaczonym kontrolerem PoKeys (przynajmniej dopoki w exe nie ma pelnej konfiguracji dla gamepada)

- w ramach koncertu zyczen: AI nie wciska sie nieproszona na fotel mechanika w lokomotywie uzytkownika przy uruchomieniu w trybie debug

2 Polubienia

684

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« dnia: 20 Maja 2017, 15:54:56 »

W okolicach Radliczyc wywaliło mnie ze znanym komunikatem.

Zaraz zaraz, komu znanym temu znanym :o  ktory to konkretnie komunikat byl, o braku pamieci czy cos innego?

Nie chcę krakać, ale jakiś czas temu grzecznie się spytałem czy są problemy z exe c➕➕ na Pokeys.

Jak juz kilkukrotnie wspomnialem nie mam dostepu do PoKeys ani zadnego tym podobnego urzadzenia, wiec nie jestem w stanie wykryc lub poprawic problemow w tym obszarze. Musi sie tym zajac osoba ktora taki dostep ma. Zrodla programu sa publicznie dostepne, a dostarczany kod jest dolaczany tak szybko jak jest to mozliwe.

1 Lubię to

685

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« dnia: 15 Maja 2017, 15:16:22 »

Tak, opoznienie dziala tak samo dla wszystkich typow -- jesli przetwornica byla z jakiegos powodu wylaczona, to od momentu spelnienia warunkow dla zalaczenia do samego zalaczenia uplynie ConverterStartDelay sekund. W pewnym sensie mozna to traktowac jako (uproszczony) czas potrzebny na pelny rozruch urzadzen.

1 Lubię to

686

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« dnia: 13 Maja 2017, 01:14:02 »

- widoczne są jakieś dziwne trójkątne artefakty związane prawdopodobnie ze słupami trakcyjnymi (vbo_trojkaty);
- niewidoczna część tekstury ramienia słupa (vbo_slup);

Te dwa sa najprawdopodobniej powiazane, tzn te farfocle to jest, z jakiegos powodu znieksztalcony, brakujacy kawalek slupa. Ten blad jest od 'dawna' i jest dziwny, bo z jakiegos powodu dotyka tylko slupa z krotka wersja poprzeczki, a tej z dluga nie. Podobnie z elektromagnesem shp -- nie wyswietla jednego boxa, gdyby tu byl szerszy blad w kodzie, powinno to chyba wplynac takze na inne modele. Tak czy owak przyjrze sie.

Trojkaty 'pod spodem' torow to nie tyle blad co optymalizacja -- zaoszczedza tak 10-20x ilosc odwolan do karty graficznej, a trojkatow w normalnych okolicznosciach nie widac, wiec raczej nie przeszkadzaja swoja obecnoscia (a kiedy kamera jest powyzej toru to nie renderuja sie w ogole)

1 Lubię to

687

Pomoc doraźna / Odp: Instalacja exe c++

« dnia: 12 Maja 2017, 20:44:13 »

Wersja x86 działa :) Zainstalowałem też wersję x64 i cały czas wywala błąd :(

Dla wersji x64 potrzebna bedzie instalacja wersji x64 dla obu redist, i wersja 64-bit dla pythona, zamieszczona troche nizej w glownym watku. Dla pewnosci mozna tez doinstalowac wersje x64 samego pythona, z https://www.python.org/ftp/python/2.7.13/python-2.7.13.amd64.msi

1 Lubię to

688

Pomoc doraźna / Odp: Instalacja exe c++

« dnia: 12 Maja 2017, 20:21:56 »

Potrzebny jest jeszcze vcredist 2015, do pobrania ze strony Microsoftu: https://www.microsoft.com/en-us/download/details.aspx?id=48145
mialem go wrzucic do uaktualnienia bibliotek ale sie przeciagnelo

1 Lubię to

689

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« dnia: 09 Maja 2017, 22:37:25 »

OK, znalazla sie przyczyna blednego zachowania w Drawinowie.

Pod sceneria zakopana jest, przyrodzenie wie po co, tarcza manewrowa wdz_tmunvis1_sem_info wyswietlajaca predkosc 0.  AI probuje zatrzymac sie przed nia w odleglosci ok 5 m, ale poniewaz sygnal jest 10 m pod powierzchnia ziemi, w efekcie "przekracza" wyznaczona przez niego linie, i rejestruje "nakazana predkosc na ostatnim semaforze: 0 km/h" no i poslusznie stoi potem do swietej Nigdy.

(poprzednio AI zatrzymywalo sie przed tarcza, bo odleglosc kalkulowana byla tylko na plaszczyznie, bez uwzglednienia roznicy poziomow. Na upartego moge przywrocic poprzedni model kalkulacji, ale to z kolei moze miec negatywne efekty w sytuacjach gdzie faktycznie wystepuje spadek albo wzniesienie terenu, wiec nie wiem czy nalezy)

tl;dr: robic scenerie porzadnie, to beda dzialac porzadnie ;/

3 Polubienia

690

Na warsztacie / Odp: Odp: Exe - konwersja na C++

« dnia: 03 Maja 2017, 12:46:11 »

Z tego co zauwazylem, to w lokomotywie hamulec napelnia sie bardziej 'leniwie' na postoju niz w ruchu, ale to akurat chyba jest 'tak jak ma byc' W czasie jazdy raczej nie ma z tym problemow. Inna sprawa jest, ze o ile sie nie myle to hamowanie powinno byc realizowane przede wszystkim przez wagony a nie lokomotywe i miedzy innymi po to wlasnie jest odluzniacz. A w wagonach z tego co widze hamulce chodza normalnie. Tak wiec nie wiem czy tutaj jest problem, trzeba eksperta :o

Jesli poprawa fps jest w ostatnich uaktualnieniach, to zapewne dlatego ze tam jest teraz troche bardziej agresywna regulacja zasiegu widocznosci, po zgloszeniach ze fps mogl byc dosc niski. Wyglada na to ze dziala :)

Uruchomilem nocne Calkowo u siebie i exe co prawda sie nie wysypalo, ale dosc wczesnie zaczelo wyprawiac cuda na kiju, rozdymajac tabelki skanowania z 16 domyslnych do ponad 20 tys. pozycji, wiec nie zdziwilbym sie gdyby tam wlasnie byly problem. Sprobuje sie temu przyjrzec, moze uda sie tam przeszczepic wersje @firleju, a w najgorszym wypadku przynajmniej znalezc i usunac przyczyne.

1 Lubię to