Strefa OMSI

https://www.facebook.com/LOTUSSimulator/...370230770/ Sprzed chwili! To jest coś, czego w OMSI będzie brakowało

Ciekawe, kiedy będzie premiera tego LOTUS-a. Ale chyba długo poczekamy. Ciekawe, czy będą tam polskie lokomotywy, i chociażby MAN 313-15. Bo ten MAN jest dość fajny

Nie będzie polskich lokomotyw oraz MANa "313-15", bo taki nie istnieje. Będzie tramwaj AdTranz GT6N i autobus MAN ND313 Lion's City DD.

Witam wszystkich (to mój pierwszy post na tym forum),

ale do rzeczy....

To co mnie najbardziej niepokoi w tym projekcie, to jest powielenie problemu, jeśli dobrze kojarzę w czym jest napisany Omsi 2, w postaci tworzenia symulatora, z bogatymi (jeśli dobrze rozumiem autorów fanpage-a) możliwościami graficznymi, zaawansowaną fizyką i możliwością jazdy (symulacji) wszelkich możliwych pojazdów komunikacji miejskiej, w Delphi.
Jeśli ten projekt faktycznie w tym języku powstaje, to "w programie" są te same problemy z wydajnością, mniejszą ilością dostępnych dla programistów tego symulatora różnych bibliotek programistycznych (grafika, fizyka itp), co w poprzedniku. Delphi, a przynajmniej tak jak ten język programowania pamiętam sprzed 10 lat, nie był tworzony z myślą o programowaniu gier czy innych systemów, gdzie wydajność i ilość danych jest wrażliwym punktem. Pomijam już fakt, że delphi nie jest ostatnimi laty szczególnie popularne w ogóle, a szczególnie wśród twórców gier.

Dla C/C++ jest mnóstwo zarówno darmowych (open source) jak i płatnych naprawdę dobrej jakości engine-ów graficznych czy fizycznych, z których korzysta konkurencja tak jak np. TML Studios czy inni twórcy gier. Pomijam już fakt że c/c++ jest szybsze, lepiej wspierane przez różne środowiska programistyczne itp. Dla mnie naturalnym wyborem, kiedy taki projekt zaczyna się niejako "od nowa", jest stworzenie go w języku najlepiej dopasowanym pod względem możliwości jakie on daje.

Nie zajmuje się zawodowo programowaniem gier, ale na moje rozeznanie Delphi + symulator to kiepskie połączenie.
Nie uszedł mojej uwadze też fakt, że mimo już paru lat od wydania Omsi 2, wciąż są tam sytuacje takie jak np. kiepsko zrobiony skrypt do jakiegoś dodatku, który powoduje błędy ochrony dostępu w głównym module aplikacji, co może oznaczać, że Omsi 2 jest kiepsko zabezpieczony przed różnymi problemami z bezpieczeństwem i jakością takich dodatków.

Rozumiem być może występujący lęk autora Omsi 2 przed typowo c++ problemami jak wskaźniki itp. ,ale jeśli już chce korzystać z języka programowania na wyższym poziomie abstrakcji, dlaczego nie użyje np. c# + jakieś engine-y jak np. Unity, których dla twórców gier jest coraz więcej. Ostatnimi laty C# zyskało bardzo dobre wsparcie, optymalizacje jeśli chodzi o techniki tej dot netowej wirtualnej maszyny i... prawdę mówiąc trochę gier już w c# powstało, wyglądają bardzo dobrze (lepiej jak Omsi 2), nie mają większych problemów z wydajnością (przykład nie z tej półki, bo to strategia wprawdzie - Europa Universalis III i IV, ale te gry też mielą sporo danych, i mają ładny, responsywny interfejs).

Biorąc pod uwagę też fakt, że jedna osoba (sic!) zajmuje się tam tworzeniem engine od nowa czy ogólnie całą stroną software-ową, robi to w delphi, że omsi 1 i omsi 2 zajęło dobre klika lat i bywa ono kapryśne, Marcel ma bardzo ambitne plany jeśli chodzi o funkcjonalność tego programu, to niestety jestem sceptyczny.

Bardzo chciałbym się pomylić, ale nie jestem pewien czy te 2 zaangażowane w ten proces osoby zdają sobie sprawę ze skali tego projektu, i czasu jaki sobie prawdopodobnie na ten cel określiły (myślę,że chodzi o perspektywę 2-4 lat - NIE są to oficjalne dane w żaden sposób), skoro już informują o tym. To że jakiś tam model tramwaju poruszą się po gridzie, na którym nic nie ma, i na tym etapie nie sypie błędami, nie znaczy, że mają już z górki. Raczej najlepsze przed nimi.

Czas pokaże.... jak zawsze

Lotus powstaje w pascalu a nie w delphi.

[Q&A]



Może ktoś to przesłuchać i przekazać ogólne informacje, jakie płyną z tego filmiku?

Pozdrawiam

Jest tam odpowiedz na moje pytanie odnośnie skrzyżowań.
Jak to odpowiedział "kajne grencen", ale detale poda w przyszłości

Wreszcie coś porządnego na szynach! No, może nareszcie coś zaawansowanego z tramwajami. Cóż, każdy z nas może wywalić listę całą stertę minusów OMSI, ale chyba nikt nie zaprzeczy, że to najbardziej rozbudowany i zaawansowany symulator autobusów jaki powstał. I tego mi brakowało w przypadku trakcyjnych kolegów. Ciekawe, czy to wypali. Albo inaczej - czy zdąży wypalić. Bo niby nic nie słychać, nic nie wiadomo, a od d6team może polecieć prawdziwa bomba... (to Ci od Advanced Tram Simulator).

(12.11.2016 05:51)flux napisał(a): [ -> ]Witam wszystkich (to mój pierwszy post na tym forum),

ale do rzeczy....

To co mnie najbardziej niepokoi w tym projekcie, to jest powielenie problemu, jeśli dobrze kojarzę w czym jest napisany Omsi 2, w postaci tworzenia symulatora, z bogatymi (jeśli dobrze rozumiem autorów fanpage-a) możliwościami graficznymi, zaawansowaną fizyką i możliwością jazdy (symulacji) wszelkich możliwych pojazdów komunikacji miejskiej, w Delphi.
Jeśli ten projekt faktycznie w tym języku powstaje, to "w programie" są te same problemy z wydajnością, mniejszą ilością dostępnych dla programistów tego symulatora różnych bibliotek programistycznych (grafika, fizyka itp), co w poprzedniku. Delphi, a przynajmniej tak jak ten język programowania pamiętam sprzed 10 lat, nie był tworzony z myślą o programowaniu gier czy innych systemów, gdzie wydajność i ilość danych jest wrażliwym punktem. Pomijam już fakt, że delphi nie jest ostatnimi laty szczególnie popularne w ogóle, a szczególnie wśród twórców gier.

Dla C/C++ jest mnóstwo zarówno darmowych (open source) jak i płatnych naprawdę dobrej jakości engine-ów graficznych czy fizycznych, z których korzysta konkurencja tak jak np. TML Studios czy inni twórcy gier. Pomijam już fakt że c/c++ jest szybsze, lepiej wspierane przez różne środowiska programistyczne itp. Dla mnie naturalnym wyborem, kiedy taki projekt zaczyna się niejako "od nowa", jest stworzenie go w języku najlepiej dopasowanym pod względem możliwości jakie on daje.
Nie zajmuje się zawodowo programowaniem gier, ale na moje rozeznanie Delphi + symulator to kiepskie połączenie.
Nie uszedł mojej uwadze też fakt, że mimo już paru lat od wydania Omsi 2, wciąż są tam sytuacje takie jak np. kiepsko zrobiony skrypt do jakiegoś dodatku, który powoduje błędy ochrony dostępu w głównym module aplikacji, co może oznaczać, że Omsi 2 jest kiepsko zabezpieczony przed różnymi problemami z bezpieczeństwem i jakością takich dodatków.

Rozumiem być może występujący lęk autora Omsi 2 przed typowo c++ problemami jak wskaźniki itp. ,ale jeśli już chce korzystać z języka programowania na wyższym poziomie abstrakcji, dlaczego nie użyje np. c# + jakieś engine-y jak np. Unity, których dla twórców gier jest coraz więcej. Ostatnimi laty C# zyskało bardzo dobre wsparcie, optymalizacje jeśli chodzi o techniki tej dot netowej wirtualnej maszyny i... prawdę mówiąc trochę gier już w c# powstało, wyglądają bardzo dobrze (lepiej jak Omsi 2), nie mają większych problemów z wydajnością (przykład nie z tej półki, bo to strategia wprawdzie - Europa Universalis III i IV, ale te gry też mielą sporo danych, i mają ładny, responsywny interfejs).

Podpisuje się pod tym. Miałem okazję napisania kilku programów w Delphi i jest dokładnie tak jak napisałeś, to środowisko nie jest przeznaczone do tworzenia bardziej zaawansowanych gier czy symulatorów.

Ja bym na miejscu autorów użył C# np. z Unity, skoro mają jakiś lęk przed C/C++.

(12.11.2016 05:51)flux napisał(a): [ -> ]Biorąc pod uwagę też fakt, że jedna osoba (sic!) zajmuje się tam tworzeniem engine od nowa czy ogólnie całą stroną software-ową, robi to w delphi, że omsi 1 i omsi 2 zajęło dobre klika lat i bywa ono kapryśne, Marcel ma bardzo ambitne plany jeśli chodzi o funkcjonalność tego programu, to niestety jestem sceptyczny.

Otóż to. Pisanie przez kilkuosobową grupę własnego silnika w dobie potężnych engine'ów, bibliotek czy nawet środowisk jest może ambitne, ale kompletnie głupie. Będzie tak, że za parę lat Lotus skończy jak OMSI 2 aktualnie. Znowu trzeba będzie od nowa pisać cały kod. Po prostu błędne koło.

(12.11.2016 10:21)CraherPL napisał(a): [ -> ]Lotus powstaje w pascalu a nie w delphi.

Delphi to środowisko oparte na Object Pascalu (obiektowe rozszerzenie Pascala). Pisanie tak dużego symulatora w czystym imperatywnym Pascalu byłoby raczej szaleństwem

Tworzenie takiej gry w Unity jest złe. Unity ma problemy z wydajnością i optymalizacją. CryEngine dobre by było