| Alternatywny runtime dla OMSI 2 – czy taki projekt ma techniczny sens? |
Cześć,
od pewnego czasu zastanawiam się nad dość eksperymentalną koncepcją i chciałbym poznać opinię osób, które znają OMSI 2 trochę głębiej od strony technicznej. Chodzi o czysto koncepcyjny na ten moment pomysł stworzenia niezależnego, współczesnego runtime'u, który potrafiłby uruchamiać zawartość przygotowaną dla OMSI 1/2 – przede wszystkim modele, pojazdy i mapy – ale bez korzystania z oryginalnego 32-bitowego silnika OMSI. Na tym etapie nie chciałbym traktować tego jako zapowiedzi konkretnego projektu ani deklaracji, że taki runtime rzeczywiście powstanie. Bardziej interesuje mnie sprawdzenie, na ile sama koncepcja jest technicznie realna i gdzie znajdowałyby się jej największe ograniczenia. Gdyby kiedykolwiek podjąć próbę realizacji czegoś takiego, wyobrażałbym sobie raczej bardzo stopniowe podejście. Na początku mogłoby to być jedynie poprawne wczytanie i wyświetlenie modelu, później obsługa jego konfiguracji, a dopiero z czasem ewentualnie kolejne elementy – pojazdy, mapy, animacje, skrypty itd. Nie chodziłoby więc o próbę napisania od razu kompletnego „OMSI 2 od nowa”. Pewnym punktem zaczepienia jest fakt, że część tego gruntu została już przez społeczność zbadana. Istnieją chociażby viewery O3D, importery oraz inne narzędzia pozwalające wczytywać modele i dane OMSI poza samą grą. Pokazuje to przynajmniej, że część formatów OMSI można interpretować niezależnie od samego programu i że przy rozważaniu takiego pomysłu istnieją już pewne doświadczenia, na których można się oprzeć. Teoretycznym celem takiego rozwiązania byłby 64-bitowy runtime pozbawiony części ograniczeń starego silnika – mogący korzystać z większej ilości pamięci, nowocześniejszego renderingu oraz, w dalszej perspektywie, lepszego zarządzania dużymi mapami – przy jednoczesnym zachowaniu możliwie dużej kompatybilności z istniejącymi DLC oraz modami. Oczywiście największym znakiem zapytania są bardziej złożone elementy: system skryptów, fizyka pojazdów, animacje, AI, pasażerowie, system mapy oraz wszystkie mniej oczywiste zachowania silnika, na których mogą polegać istniejące dodatki. Zakładam też, że gdyby kiedykolwiek taki eksperyment był rozwijany, pełna obsługa tych rzeczy nie musiałaby istnieć od początku – pierwszym celem mógłby być jedynie niewielki proof of concept. I właśnie tutaj najbardziej interesuje mnie Wasza opinia: co Waszym zdaniem rzeczywiście stałoby na przeszkodzie stworzeniu takiego alternatywnego runtime'u? Czy są w OMSI elementy, które byłyby szczególnie trudne do odtworzenia albo mogłyby sprawić, że wysoka kompatybilność byłaby w praktyce bardzo trudna lub wręcz nieosiągalna? A z drugiej strony – które elementy uważacie za realnie możliwe do odtworzenia, nawet jeżeli wymagałoby to sporo pracy? Czy znacie istniejące narzędzia, projekty, dokumentację albo wcześniejsze próby, które mogłyby być przydatne przy ocenie takiego pomysłu? Na razie traktuję to wyłącznie jako badanie wykonalności i próbę lepszego zrozumienia problemu. Nie chciałbym na tym etapie niczego zapowiadać ani deklarować – jestem po prostu ciekaw, jak wygląda to z perspektywy osób mających większe doświadczenie z techniczną stroną OMSI. Z góry dzięki za wszelkie uwagi, doświadczenia i tropy.
Jest to jak najbardziej do osiągnięcia. Posiadając odpowiednie narzędzia typu Ghidra, IDA, Frida jesteś w stanie sie dokopać do całego silnika OMSI. Co prawda te programy nie rozszyfrują żadnej nazwy funkcji ani komentarzy, ale jesteś w stanie coś zobaczyć. Zrobienie takiego czegoś wymagałoby poświęcenia ogromnej ilości czasu, mówimy tu o latach pracy, a nie wydaje mi sie że ta gra jest warta zachodu i ratowania.
U mnie działa ¯\_(ツ)_/¯
|
| Użytkownicy przeglądający ten wątek: |
| 1 gości |

