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 - HTD

Strony: [1]
1
Zauważyłem, że na sceneriach komunikacja radiowa idzie na kanale 1, co jest niezgodne z rozkładem i podpowiedziami pomocnika. Wyjdzie jakaś poprawka do tego?

2
Symulator / GUI symulatora - jak zwiększyć rozmiar tekstu?
« dnia: 14 Września 2023, 21:46:13 »
Witam.

Na moim komputerze MaSzyna działa podobnie wolno lub szybko w każdej rozdzielczości, więc najlepiej używałbym 4K, bo symulator wygląda w niej najlepiej.

Jest jednak problem z interfejsem i oknami symulatora. Ich rozdzielczość i skalowanie nie zmienia się wraz ze wzrostem rozdzielczości. W 4K napisy są przy moim wzroku kompletnie nieczytelne. Co ciekawe, w 4K są za to idealnie czytelne przyrządy samej lokomotywy, wyświetlacze LED i LCD, zegary. W 1080 widać tekst w okienkach pomocniczych, ale już teksty oryginalnych przyrządów są niewyraźne.

Czy jest gdzieś jakiś parametr w konfiguracji albo skrót klawiszowy czy jakikolwiek inny sposób zwiększenia skalowania tekstu w tych oknach?

BTW, te okienka wyglądają jak ImGUI, zgadłem? ;) Większość apek na ImGUI ma ten sam problem - kompletny brak czytelności w 4K. Ale chyba to się gdzieś ustawia?

3
Pomoc doraźna / Odp: MaSzyna 21.04 - problemy
« dnia: 04 Maja 2021, 21:01:47 »
Miałem na początku problem z torrentem, ale jak odczekałem trochę to ruszył i się pobrał. Jakby co to zostawiłem na seedowaniu.

4
Bieżące Symulatorowe / Czy jest planowany rozwój starych scenariuszy?
« dnia: 21 Listopada 2020, 06:49:20 »
Tak patrzę, że w ostatnim wydaniu pojawiło się sporo nowych scenariuszy. Stare trasy, odświeżone, ale przede wszystkim - nowy ruch, gdzie wszystko "żyje".
Pamiętam pierwszą tak zrobioną trasę - to było nowe Całkowo, gdzie semafory i zdarzenia nie rozpoczynały się o "10:53" albo "bo pojazd gracza minął 37 kilometr", tylko wynikały z ruchu, który w dodatku losowo mógł wyglądać za każdym powtórzeniem trochę inaczej.

Tymczasem, stare scenariusze - po prostu "brain dead". Nic nie działa. Niby pociąg jedzie, ale jak jest to pasażerski, nie widać związku jazdy z rozkładem. Nie widać komunikatu o "wymianie pasażerskiej". Działanie sygnalizacji na trasie dziwne i jakieś niepasujące. Nawet czasem rozkład nie pasuje, jakby był robiony dla innej wersji trasy czy składu. Ba - odpalam sobie Bałtyk, robię próbę radia, oczywiście brak odpowiedzi. Rozumiem - sterowanie scenerii musi mieć odpowiedź na konkretnym kanale zapisane, a to stara sceneria i nie ma. Byłoby fajnie, jakby ktoś to ruszył i wyświadczył tym starym sceneriom przysługę poprawiając dosłownie drobiazgi. Przecież to bez porównania łatwiejsze i szybsze, niż dorabianie nowej grafiki, dźwięków, modeli czy torów. Wystarczyłoby przypisać sygnalizację właściwie, dodać obsługę radia, wywalić "naciśnij Shift+1" - pozostałość z czasu, kiedy w sterowaniu nie szło nic zrobić normalnie, tylko "na klawisz" ludzie robili. Serio, byłoby 100x lepiej jakby chociaż to działało. Jakby pomocnik pokazywał rzeczywiste ograniczenia prędkości. Nie trzeba od razu robić nowego ruchu. Teraz efekt jest taki, że stare scenerie wyglądają na zwyczajnie zepsute. Gdyby chociaż przypisać sygnalizację i wskaźniki do torów, ten efekt nie byłby tak rażący.

Są jakieś plany rozwoju tego? Widzę, że Drawinowo jest tak ładnie poprawione. Może dlatego, że w ogóle nie było przejezdne przez długi czas. Jest szansa, że stare Bałtyki i Zwierzyńce doczekają się jakiegoś nowego sterowania? Może Quark? (Ostatnio był nieprzejezdny, jak kilka razy utknąłem na "zawieszonym" S1 to dałem sobie spokój z tą scenerią).

Jeszcze jedno, jak są nowe które zastępują stare, to może te stare po prostu zaorać i usunąć? Tak było zrobione z Całkowem i misją SN-61. Nowa wersja jest super.

5
Bocznica / EN62 - nie działa sprężarka
« dnia: 27 Września 2020, 23:17:13 »
Odpalam EN62 zgodnie z instrukcją. Podniesiony przedni patyk, włączony wyłącznik szybki... I nic. Wskazówka ciśnienia w ZG (żółta) stoi. W instrukcji jest napisane, że mam czekać na nabicie 5 barów. No nie nabija się nic.

Można skasować? Nie włączyłem szybkiego. Ta lampka świeci jak szybki jest wyłączony. To mnie zmyliło. Już działa wszystko.

6
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 28 Kwietnia 2017, 22:15:16 »
(...) ale przy tym już mogą się posypać scenariusze, w których np. długi skład towarowy musi ruszyć zaraz po uruchomieniu symulacji.

Jeśli skład musi ruszyć zaraz po uruchomieniu symulacji ustawia mu się prędkość początkową 0.1, inaczej nie może ruszyć natychmiast nawet na starym exe.
Pamiętam, że zaraz przed ukończeniem ostatniej paczki całościowej była jakaś zmiana, która powodowała, że nie dało rady podnieść patyków przed podpompowaniem sprężarką pomocniczą. Potem zostało to "poprawione", i jak dla mnie: szkoda. Wolałem wersję z prawdziwym "zimnym startem". W TD2 start jest bardzo uproszczony, ale ciśnienie w ZG jest zero i konieczne jest użycie odluźniacza żeby odhamować skład.

Ktoś tam na YT też narzekał, że w takim Trainz procedura uruchomienia takiej siódemki czy byka wygląda w miarę poważnie, a w MaSzynie jest uproszczona do bólu. Dlatego z tymi zaworami to jest bardzo cenna uwaga i warto to wdrożyć nawet jeśli ujawni to błędy w niektórych scenariuszach. Jak mówiłem, jak skład ma ruszyć od razu, to ma wpisaną prędkość 0.1, czyli jest "wstępnie uruchomiony", ma nabite ciśnienie w ZG i jest gotowy do odjazdu. Gorzej, jak ktoś założył, że powiedzmy skład ruszy w ciągu minuty, wtedy będzie problem, bo zgodnie z właściwym działaniem zaworów nie ma szans żeby w tym czasie ruszył. No i oczywiście do tego AI musi też potrafić prawidłowo wystartować zgodnie z poprawioną procedurą. Inna sprawa, że poprawienie takich błędów w scenariuszach jest (zgaduję) bardzo proste, wystarczy im po prostu ustawić prędkość początkową i po krzyku. Można to chyba nawet zrobić bezpiecznie dla wszystkich składów prowadzonych przez AI i raczej nie powinno się nic posypać specjalnie.

7
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 10 Kwietnia 2017, 20:39:32 »
Tak, ale tylko oddać to można sterowaniem za pomocą myszy. Klawiatura się do tego nie nadaje.

Właśnie chciałem to napisać ;) Z uwagą "albo pulpitu fizycznego". Ogólnie interfejs klawiaturowy użyty do sterowania z fizycznych pulpitów sprawdził się bardzo dobrze, ale troszkę w charakterze prowizorki. Byłoby chyba lepiej dla ludzi tworzących / rozwijających pulpity, gdyby dać im bardziej bezpośredni interface, czyli raczej komendy symulatora niż mapowane naciśnięcia klawiszy.
Nie można zapominać o tych urządzeniach, które są, dlatego "tryb kompatybilności" być musi, żeby te wspaniałe urządzenia nie przestały działać z nowymi wersjami. Postuluję jednak żeby nowe urządzenia miały interfejs kompletnie pomijający obsługę klawiatury. Zamiast tego możliwość wysłania "podnieś pantograf B" albo odczytania "czy przełącznik P123 jest włączony?". Tzn zamiast P123 być może nazwa funkcji jaką spełnia, jeśli jest to funkcja wspólna dla wielu pojazdów. Nazwy z numerkiem mogą mieć "uniwersale". Takie podejście mogłoby ułatwiać tworzenie realistycznego działania różnych wyłączników i przełączników bez specjalnego kombinowania. No i różne rodzaje sterowania byłyby niezależne od siebie. Tzn zmiany w układzie klawiatury nie powodowałyby żadnych zmian w obsłudze jakiegokolwiek podłączonego do MaSzyny pulpitu.

8
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 08 Kwietnia 2017, 19:39:02 »
Tak jak lubię realizm, tak mi się to wydaje troszkę zbyt skomplikowane. Sterowanie z klawiatury powinno być przede wszystkim spójne. Wiadomo, że klawiatura to nie rzeczywisty pulpit, bo każdy pulpit jest trochę inny, a klawiatury standardowe. Wydaje mi się, że ten sam klawisz w każdej lokomotywie powinien robić to samo, a jeśli nie może, to po prostu nie powinien działać. Sens by miało za to, żeby przy sterowaniu myszą (klikalne hebelki) jak najbardziej działało to jak w rzeczywistych lokomotywach, czyli zależnie od tego która kabina i która wersja loka. Tak samo bardzo szczegółowe opcje sterowania powinny być dostępne w API dla urządzeń zewnętrznych innych niż klawiatura.

Dla zachowania spójności - klawisz wciśnięty z shiftem zawsze włączał dany włącznik, bez shifta wyłączał. Jestem za tym, żeby tak zostało. Potem doszło mniej intuicyjne kręcenie przełącznikami obrotowymi, też z shiftem w jedną stronę, bez shifta w drugą. Ale jest w tym jakaś logika.

9
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 29 Marca 2017, 08:20:44 »
Czy dałoby radę zrobić coś, żeby dźwięk "runningnoise" miał głośność zależną od prędkości? Bardzo irytujące jest, że ten dźwięk startuje i kończy się odtwarzać nagle. Szczególnie dokuczliwe w EP05 / EP09. Dalej - zauważyłem, że ten dźwięk odtwarza się z głośnością niezależną od obecności w kabinie czy nawet odległości od składu. Wysiadam z kamerą, pociąg odjeżdża, a nadal słyszę dźwięk z pełną głośnością, nawet, jeśli pociągu już nawet nie widać.

Czy dałoby się dodać widok interfejsu z celownikiem na środku ekranu i współrzędnymi tego celownika wyświetlanymi cały czas (bez żadnych innych danych)? Oczywiście kierunek ustawienia kamery również na tym widoku byłby potrzebny.

Jak wyglądają plany połączenia różnych wersji exe? Czy jest szansa, że w najbliższej przyszłości znikną wersje DL / VBO z shaderami i bez? Do ostatniej wersji NG wersja VBO miała problemy z oświetleniem na niektórych sceneriach, szczególnie L053, zauważyłem, że ostatnia wersja chyba rozwiązała ten problem, za to na x64 połowa scenerii się wysypuje bez VBO. Skoro VBO już jakoś działa a DL się teraz sypie, może porzucić DL na dobre? Jeśli światła na shaderach działają już bardzo dobrze, nie mogą zostać? No tylko jeszcze efekt tego przepalenia został. Usunięcie go nie będzie trywialne, bo jakby po prostu tylko przyciemnić wszystko to będzie za ciemno w nocy. A chodzi w zasadzie o to, żeby tylko w dzień było ciemniej, a w nocy dokładnie tak jak jest. Z oświetleniem przyrządów nie tyle chodzi o to, żeby podświetlenie było ciemniejsze, ale żeby nie wchodziło w nienaturalne nasycenie (przepalenie). Jasność jest OK, ale coś nie tak jest kolorami i gammą.

Ostatnia sprawa to trzęsienie i miganie. To są 2 różne błędy. Pierwszy to błąd wersji z shaderami. Na moim sprzęcie trzęsienie jest bardzo szybkie, serio, jakby z 20-30FPS miało. Zawsze w poziomie i tylko w poziomie. Drugi błąd to trzęsienie i miganie obiektów. Trzęsienie widać na podsypkach, jakby na zmianę rysowały się 2 wersje podsypek nieco przesunięte. To zmienia się wolno, od 1 do kilku razy na sekundę. W niektórych miejscach efekt jest bardzo intensywny. To było w MaSzynie od zawsze, i podobno nie da się nigdy poprawić. Nie da się? Ale jest jeszcze druga wersja tego samego problemu jednakże jeszcze bardziej irytująca: ustalanie czy obiekt jest za czy przed innym. To powoduje, że niektóre obiekty pojawiają się i znikają raz do kilku razy na sekundę, albo zależnie od kąta patrzenia kamery. Stoję sobie na peronie i widzę jak miga budynek czy nawet kawałek górki. Jeśli kamera jest nieruchoma i obiekty są nieruchome - dlaczego poruszają się pomiędzy kolejnymi klatkami?

10
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 19 Marca 2017, 09:52:28 »
Dzięki, żadne umieszczane wersje x64 (poza tą) nie uruchamiały się u mnie, niezależnie od DLL-ek. Jedyne pasujące DLL-ki wgrywał @Milek, ale ostatnio nie mogłem się nawet do nich dokopać.

Widzę, że to się coraz bardziej stabilne robi. Pytanie, czy jest w planach dodanie wyświetlania bieżącej prędkości i parametrów lokomotywy w trybie gracza? Chodzi mi o typowo użytkowy widok, jak w komercyjnych symulatorach pociągów typu Trainz / MSTS. Tzn nie chodzi o graficzny bajer, ale możliwość odczytania tego samego co jest na pulpicie bez patrzenia na pulpit. Czyli - co mam na nastawniku, manometrach i haslerze.

Druga sprawa: trzęsienie obrazu i bufor Z. To jest w trakcie przerabiania? Obserwuję zmniejszenie trzęsienia krawędzi torów, ale za to jest teraz inny artefakt, którego nie było wcześniej: Jak mam drzewo i krzaczek przed drzewem (sceneria L053, dzień) silnik nie może się zdecydować, czy krzaczek ma zasłaniać drzewo, czy udawać że jest za drzewem. Poprzednio miałem 60 takich "wersji" na sekundę, teraz mam dokładnie co sekundę. Czasem błąd jest grubszy: drzewa nie mogą się zdecydować czy są przed budynkiem czy za budynkiem.

No i w końcu kwestia shaderów. Nie rozumiem tego do końca. Dla karty graficznej wszystko co ona jest w stanie zrozumieć to shader. Więc nie bardzo widzę, jak MaSzyna może wyświetlać cokolwiek na DX czy OpenGL BEZ shaderów. To raczej niemożliwe, więc pewnie kwestia języka i żargonu, prosiłbym o wytłumaczenie dla jasności.

Oświetlenie na niektórych trasach wygląda nieźle, na niektórych troszkę gorzej, na niektórych tragicznie, w zależności od wielkości trójkątów terenu. Strzelam, że dopiero kombinacja vertex-shaderów z pixel-shaderami będzie załatwiać sprawę, ale zbudowanie pixel shaderów biorących pod uwagę geometryczne położenie wierzchołków nie jest rzeczą trywialną i raczej nie powstanie "w tym tygodniu", a nawet "w tym miesiącu". Dobrze zgaduję?

Ostatnie pytanie: VBO. Czy ta opcja w ogóle działa i powinniśmy testować z włączoną i wyłączoną? Z tego co ja testowałem w ostatnich wersjach - nie widzę żadnej różnicy, ale znów być może różnica nie jest widoczna w każdym miejscu.

Z różnicy którą widzę: dużo wyższy FPS. Poprawiony czas ładowania. Trzęsienie obiektów ma mniejszą częstotliwość (to na plus).

Na marginesie, testowałem SN61 - brak działania rozkładu dla tej lokomotywy. Rozkład się przewija jak ją podmienię na stonkę.

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

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

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

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

15
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 03 Marca 2017, 11:14:46 »
Oto mniej więcej jak wyobrażam sobie ruch po kabinie:
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.

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

17
Bieżące Symulatorowe / Odp: MaSzyna vs TD2
« dnia: 28 Lutego 2017, 12:36:01 »
Niby są rzeczy, których się nie da, ale od czasu do czasu ktoś nie wie, że się nie da ;)

Największą słabością MaSzyny jest IMHO ten C++. Język przeszłości, w którym teoretycznie można napisać wszystko, ale potrzebny na to czas wydaje się puchnąć tak szybko, jakby P zmieniało się w NP. C# jest dużo lepszym rozwiązaniem, a od czasu .NET Core 1.0 - idealnym. (Niedługo wychodzi Core 2.0) Gdyby przepisać MaSzynę w C# z użyciem .NET Core, mogłaby chodzić pod Linuxem bez Wine. Unity to jedna z opcji. Całkiem niezła, ale jest jeszcze UnrealEngine, a ostatnio pomyślałem nawet, że można by stary silnik MaSzyny też przepisać po nowemu. Chociaż mam ogromny staż w kodowaniu, nigdy nie zajmowałem się grafiką (w sensie gamedev). Mimo tego, jak zacząłem sobie czytać w czasie wolnym (a mam go tyle co nic) o działaniu silników 3D - to nie jest aż takie magiczne jak się wydawało. I absolutnie nie wymaga C++. Dobrą grafikę na shader-ach da się robić w JavaScript-cie, więc po prostu nie widzę żadnego argumentu za C++ poza takim, że po prostu większość kodu MaSzyny jest w nim napisana. Całe rysowanie i tak robi GPU, a programowanie GPU (shader-y) nie zależą w ogóle od języka aplikacji. Co do liczenia fizyki w czasie rzeczywistym - więcej dla wydajności da optymalizacja na poziomie algorytmów niż mikro-optymalizacje na niskim poziomie. Lagi w MaSzynie nie powstają z powodu nieoptymalnej obsługi czy przydzielania pamięci, powstają, bo symulator wykonuje zbyt wiele operacji (nie pomija kroków nieistotnych, wykonuje nieoptymalne obliczenia itd.).

Exe-majstrzy już się zgodzili, że główne założenia konstrukcyjne stojące za budową MaSzyny są błędne i do zmiany. Np scenariusze. Powstały nawet nowe całkiem sensowne koncepcje zmiany tego. Owszem, po drodze będzie pewien problem z konwersją istniejących rzeczy, ale da się to zrobić. Skrypty muszą być i tu i tu. To jedyny sensowny sposób opisywania pojazdów czy scenariuszy. No niby można się uprzeć na format binarny, ale to nie byłoby sensowne.

Myślę, że i jeden i drugi symulator może osiągnąć sporo. Nawet różnice pomiędzy nimi mogą się kiedyś zacząć zacierać. Tak sobie myślę, że rywalizacja pomiędzy załogami ma też swoje plusy. Może TD2 będzie miało kiedyś lepszy tryb jednoosobowy. A MaSzyna doczeka się lepszego silnika graficznego i sterowania ruchem. To tylko po prostu zajmie jeszcze kilka lat.

MaSzyna ma fory w postaci ogromnej ilości zasobów audio-video. Ciężko będzie komukolwiek przebić MaSzynę pod względem ilości taboru. Z kolei TD2 ma fory w postaci nowocześniejszej technologii. Szanse są wyrównane. Ciekawe co będzie pierwsze - MaSzyna nadrobi zapóźnienie techniczne, czy TD2 nadrobi bazę taboru i scenerii. Nie mam pojęcia.

Jeszcze niedawno można by pomyśleć, że MaSzyna umiera ze starości. Przeszkodą nie do przeskoczenia był Borland. Ale znalazł się taki, co nie wiedział, że się nie da i przepisał ;) I teraz rozwój idzie aż furczy.

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

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

Strony: [1]