Symulator EU07 (i nie tylko) > Na warsztacie
Patch_MaSzyna_10_14
HTD:
A tak na marginesie - wgrałem sobie z paczki TGA i jest dużo lepiej. Co do czasu wgrywania - nie zauważam różnicy. Ładowanie i parsowanie skryptów zajmuje sporo - ale tu pomóc mógłby tylko kompilator do jakiegoś bytecode, żeby wszystko z scn i include pakowało się do pliku binarnego. Przykład: Drawinowo - tekstur nie więcej niż w innych sceneriach - długość trasy rekordowa - rekordowy czas ładowania (uruchamiania).
Najlepiej - TGA jako paczka opcjonalna, ale wystawiona na stronie głównej projektu, aktualizowana o nowe tekstury.
BTW, gdybym miał źródła silnika, zrobiłbym kompilator skryptów. A całość scenerii spakowałbym 7z i czytał w exe bezpośrednio z niego. Co do debugowania - pliki źródłowe byłyby kompilowane (i pakowane) za pierwszym uruchomieniem.
Ra:
--- Cytat: HTD w 24 Listopada 2014, 01:38:31 ---A tak na marginesie - wgrałem sobie z paczki TGA i jest dużo lepiej. Co do czasu wgrywania - nie zauważam różnicy.
--- Koniec cytatu ---
Przy jednym pliku różnica jest niezauważalna. Natomiast dla TGA są tworzone mipmapy podczas wczytywania, co zajmuje trochę czasu. DDS ma gotowe mipmapy w pliku.
--- Cytat: HTD w 24 Listopada 2014, 01:38:31 ---BTW, gdybym miał źródła silnika, zrobiłbym kompilator skryptów. A całość scenerii spakowałbym 7z i czytał w exe bezpośrednio z niego. Co do debugowania - pliki źródłowe byłyby kompilowane (i pakowane) za pierwszym uruchomieniem.
--- Koniec cytatu ---
Być może wczytywało by się nie szybciej, ale nie załatwiło by żadnego innego problemu. Gdybym ja miał czas, to bym zrobił progresywne wczytywanie fragmentów scenerii z RSF, a także zapis wewnętrznych struktur z możliwością ich szybkiego wczytania. Pytanie jest, czy jest sens inwestować czas w doraźne rozwiązania, które fragmentarycznie coś poprawią, a nie załatwią problemu kompleksowo i nie wiadomo jakie skutki uboczne wywołają?
HTD:
Dlatego ogólnie DDS musi być, to jest domyślne dla DirectX i najszybsze. Zrobiłbym wyjątek WYŁĄCZNIE dla tekstur nieba, bo to są największe tekstury w symulatorze, a przez to, że największe, także najbardziej narażone na widoczność artefaktów kompresji. Pewnym kompromisem jest też użycie DDS bez kompresji (testowałem, nie działa w bieżącej wersji).
Co to znaczy: "nie załatwiałoby żadnego problemu"? Popraw mnie jeśli się mylę, ale symulator musi gdzieś przetworzyć każdy jeden wierzchołek z tekstu na liczbę zmiennoprzecinkową, a przy ilości wierzchołków występujących w scenerii czas tego przetwarzania chyba MA znaczenie? Dalej przy każdym jednym zdarzeniu wszystkie jego parametry muszą być najpierw rozpoznane, następnie przetworzone na liczby stało lub zmiennoprzecinkowe (lub przekazane dalej jako tekst). Nie wiem czy identyfikatory są w programie wyszukiwane w tekście, czy może gdzieś po drodze tworzony jest ich indeks i wyszukiwane są po nim? Tak czy inaczej - indeks tworzony byłby podczas kompilacji - ten etap gdyby był w exe mógłby zostać pominięty. Jeśli wyszukiwanie jest bezpośrednie - tym lepiej - dostajesz gratis indeks i natychmiastowe wskazanie na obiekt.
Co do skutków ubocznych - jeśli implementacja formatu jest zupełna (czyli każda konstrukcja składniowa ma odpowiednik binarny) - nie może to wywołać żadnych skutków ubocznych poza przyśpieszeniem uruchamiania. Oczywiście zakładając, że kompilator i część konsumująca plik binarny nie ma błędów :)
Co do nowych elementów formatu - znów, co za problem? Format binarny może być otwarty, z możliwością dodawania dowolnej ilości nowych struktur. Struktury nieznane mogłyby być ignorowane przez loader, nowa wersja mogłaby je czytać i używać. I jeszcze jeden "gratis" - sprawdzenie poprawności. Podobnie jak z kompilowaniem kodu - część błędów wskaże kompilator zanim nawet spróbujesz coś uruchomić. Dodatkowo tu miałbyś możliwość dowolnej zmiany języka skryptowego. Nawet użycia kilku. Kwestia napisania kompilatora, którego "wiedza" ogranicza się do formatu binarnego, o bebechach softu nie musi wiedzieć nic. Może Ci 10 dev-ów pisać na raz 10 kompilatorów ;) Główny exe dostaje tę samą binarkę na wejściu, więc go nie obchodzi w jakim języku ktoś oskryptował scenerię.
Co do debugowania tego - tu byłoby troszkę trudniej - exe nie może już wskazać linii źródła, która robi konkretną rzecz. Co najwyżej rodzaj operacji i symbole (podobnie jest w .NET - na podstawie indeksu symboli można odtworzyć mniej więcej kod źródłowy z kodu binarnego). Nic niemożliwego jednym słowem. Oczywiście nie zrobisz wszystkiego sam, bo to jest jedyna niemożliwa rzecz :)
Odnoszę wrażenie, że chciałbyś zrobić wszystko na raz, a to jest, z całym szacunkiem - ponad siły jakiegokolwiek człowieka piszącego kod "po godzinach". Bez rozbicia kodu na moduły rozwijane przez różnych dev-ów szybkiego postępu nie będzie. Samo rozbicie na takie moduły to spore wyzwanie - zadanie dla głównego architekta, ale z pewnością jest prostsze i szybsze, niż zaimplementowanie tony nowych ficzerów. W obecnej bazie kodowej pewnie wszystko jest zależne od wszystkiego, i nic nie możesz zmienić bez ruszania całości. Po rozprzęgnięciu integralność wymuszają interfejsy, każdą rzecz możesz sobie spokojnie zmieniać, a jak trzeba, to nawet i interfejs możesz zmienić - ale konsekwencje tego będą już bardziej jawne i oczywiste.
Ostatnia uwaga - wszystko co jest powinno być przetwarzane na zasadzie kompatybilności wstecz. Nie szkodzi, że zrobisz nowy format obiektów. Dołożysz do tego import starych i po krzyku. W ten sposób nic nie będzie z niczym konfliktować. Nowe scenerie nie muszą banglać ze starym programem więc tu sprawa jest prosta. Jak masz nowy format danych dla exe, możesz główny program znacznie bardziej zmodyfikować bez ryzyka, że z istniejącymi danymi się wysypie. Istniejące dane będą przechodzić przez konwersję - więc jeśli coś nie bangla to nie ruszasz głównego kodu, tylko konwerter. Wg mnie nie da się rozwiązać problemu kompleksowo, jak to nazywasz, bo to wiązałoby się z napisaniem aplikacji od zera, a tak się nie robi. Przemysłowy algorytm jest taki, że odsprzęgasz części kodu do modułów, zmieniasz moduły. I to nie tak, że rozbijasz wszystko na moduły. Nie. Wydzielasz drobne fragmenty do modułów. Po małym kawałeczku.
finarfin:
W ustawieniach nie widzę opcji "wyłączania spadków napięć podczas jazdy". Ta opcja została usunięta celowo czy u mnie jest coś nie tak?
Ra:
Nie ma możliwości wyłączenia obliczania napięcia na pantografie, jeśli trafia on na drut. Można tylko wyłączyć łamanie oraz zrobić wirtualne napięcie, jeśli pantograf nie trafi na drut. Można też wyłączyć wczytywanie sieci trakcyjnej, wtedy pantografy mają wirtualny prąd wszędzie, ale nie ma wcale słupów ani drutów.
Dodano: 25 Listopada 2014, 16:54:06
--- Cytat: HTD w 24 Listopada 2014, 08:32:14 ---Co to znaczy: "nie załatwiałoby żadnego problemu"? Popraw mnie jeśli się mylę, ale symulator musi gdzieś przetworzyć każdy jeden wierzchołek z tekstu na liczbę zmiennoprzecinkową, a przy ilości wierzchołków występujących w scenerii czas tego przetwarzania chyba MA znaczenie? (...)
--- Koniec cytatu ---
Podstawowy problem ze sceneriami jest taki, że są one rozległe (obecnie do 200km). OpenGL używa czterobajtowych float, który ma mantysę o 23 bitach — efekt jest taki, że każde 8km oddalenia od osi to jest 1mm błędu systematycznego każdego wykonywanego działania. Błędy te powodują drgania obiektów względem siebie. Jest kilka metod ograniczenia wartości bezwzględnej tego błędu, każda z nich ma jakieś wady. Ja zmierzam w kierunku podzielenia scenerii na komórki (fragmenty), których średnica będzie rzędu 16km (i odległość od środka nie przekroczy 8km). Dodatkowo da to możliwość doczytywania potrzebnych komórek w miarę symulacji. Aby wprowadzić takie zmiany konieczne jest dogłębne przegrzebanie struktury scenerii w pamięci. I ja nie widzę sensu zajmowania się optymalizacją wczytywania przed uruchomieniem symulacji komórek. Tzn. jeśli miałbym wybór pomiędzy optymalizacją a zmianą struktury scenerii, to wolałbym poświęcić czas na zmianę struktury. Ryzyko jest takie, że optymalizacja wykonana w pierwszej kolejności mogłaby okazać się bezwartościowa po wykonaniu zmiany struktury (ale być może nie). Obecnie gotowa jest jedna komórki scenerii (Mydelniczka), kolejnej niewiele brakuje (Tarniowo2, trzeba odciąć zbędne tam tory). Być może kiedyś da się wydzielać komórki programowo, ale na początek wolę robić ręcznie. Ponadto w obecnej ankiecie nikt nie zgłaszał, że czas wczytywania jest kluczowym problemem, którym należałoby się zająć — a tak było w ankiecie przeprowadzonej kilka lat temu.
Obiekty są indeksowane po nazwach, indeks ma wyszukiwanie binarne. Nie wszystkie typy obiektów są objęte indeksowaniem. Przy obecnie opublikowanych sceneriach indeksowanie nie daje zauważalnych korzyści, ale mamy roboczą scenerię na 3000km torów i tam wyszukanie toru po nazwie trwało zbyt długo. Struktura gromadząca nazwy i wskaźniki do obiektów zajmuje obecnie 64MB albo 128MB.
--- Cytat: HTD w 24 Listopada 2014, 08:32:14 ---Bez rozbicia kodu na moduły rozwijane przez różnych dev-ów szybkiego postępu nie będzie. Samo rozbicie na takie moduły to spore wyzwanie - zadanie dla głównego architekta, ale z pewnością jest prostsze i szybsze, niż zaimplementowanie tony nowych ficzerów. W obecnej bazie kodowej pewnie wszystko jest zależne od wszystkiego, i nic nie możesz zmienić bez ruszania całości.
--- Koniec cytatu ---
Nie, jest nawet gorzej. Obecna struktura danych jest zła. Sceneria przechowywana w pamięci jest jedną całością, a potrzebne jest jej podzielenie. Pojazdy za to są niepotrzebnie rozdzielone na dwa obiekty, z których jeden jest częściowo w Pascalu. Kabiny są przesiąknięte odczytami klawiatury. Nie ma sensu optymalizowanie czy modułowanie obecnej struktury, bo jej możliwości rozwoju już się wyczerpały. Wiele rzeczy trzeba zrobić w zupełnie inny sposób. Z kolei ja nie mam ambicji ani koncepcji na tworzenie symulatora od zera, wolę przerabiać to, co jest dostępne i z zachowaniem ciągłości funkcjonowania (czyli możliwie dużej zgodności z poprzednią wersją).
Nawigacja
[#] Następna strona
Idź do wersji pełnej