Symulator EU07 (i nie tylko) > Na warsztacie
Planowane zmiany w exe
firleju:
@tmj: no ale po co Ci elastyczny wrapper który zajmuje się tylko przekazywaniem danych dalej. Ponadto wagony skrajne w zespole muszę mieć wskaźniki na wagony skrajne w innych zespołach, gdyż inaczej nie policzysz hamulców oraz sił na sprzęgach. Oczywiście można inaczej zorganizować dane, żeby nie było wskaźników bezpośrednio do pojazdów tylko do potrzebnych danych, ale wtedy te dane trzeba trzymać na poziomie pociągu a nie zespołu (co nie znaczy, że pociąg ma robić z nimi cokolwiek poza trzymaniem). Nie widzę sensu istnienia dodatkowego poziomu abstrakcji, który w 99% przypadków będzie się sprowadzał do zwiększania opóźnień a nie będzie nic wnosił.
Moją myślą było to, żeby zespół miał taki sam interfejs jak pojazd, ale nie był pojazdem. Tak, żeby pociąg miał zestaw zespołów / pojazdów o tym samym interfejsie. W przypadku zespołu dochodziłoby odpowiednie zarządzanie informacją w stosunku do pojazdów wewnątrz. W przypadku pojazdów nie ma takiej potrzeby żeby coś tam było wyżej. Przynajmniej ja takiej nie widzę.
Troszkę się zapętliliśmy w dyskusji. Trzeba konkretnie rozpisać co dana klasa miałaby trzymać za informację i jakie mieć API do poszczególnych warstw wyższej i niższej oraz między tym samym poziomem. Inaczej do niczego nie dojdziemy.
@yB: a co z liczeniem sił pomiędzy pojazdami wewnątrz zespołu? To też trzeba liczyć bo przecież to nie jest monolit.
Milek7:
Moim zdaniem trzeba pozbyć się zależności od windowsizmów i wykorzystać wieloplatformowe biblioteki:
- okienka, mysz i klawiatura, tworzenie kontekstu GL: Trzeba wywalić to dziwne tworzenie kontekstu WGL, jak i windowsową obsługę komunikatów. GLUT to już trochę zabytek, więc pewnie lepsze będzie popularne GLFW. Ze względu na to że WM_COPYDATA jest wykorzystywane do jakiegoś IPC, to będzie trzeba je czymś zastąpić, najprościej pewnie zwykłym socketem. (na win pewnie zwykły tcp na localhoście, na unixach można socketem na pliku). Chociaż właściwie to nie wiem czy to WM_COPYDATA jest wykorzystywane do czegoś praktycznego, czy jakaś nieużywana pozostałość?
- renderowanie fontów: Jak nie będzie ani WGL ani GLUT, to trzeba sobie jakoś poradzić z wyświetlaniem tekstu. Zwykle wykorzystuje się FreeType żeby wyrenderować tekst do tekstury.
- dźwięk: Oczywiście trzeba pozbyć się DirectSound. OpenAL wygląda sensownie.
- LPT: AD 2017 i LPT? To bym wywalił w ogóle.
- UART: Tu coś trzeba pewnie wymyślić. Albo znaleźć jakąś wieloplatformową libkę, albo napisać po prostu dwie implementacje pod windowsa i unixy, z tym nie powinno być dużo problemów.
- PoKeys55: Nie patrzyłem dokładnie co to za wynalazek, ale wygląda na jakieś proste USB. Jeżeli czyste usb to libusb-1.0, jeżeli hid to HIDAPI.
Co do modernizacji silnika graficznego, to koniecznie trzeba pozbyć się fixed pipeline. Absolutne minimum jakie można wspierać to OpenGL 2.0, chociaż trzeba by się zorientować czy komuś to w ogóle potrzebne, bo nowocześniej i wygodniej by było robić na 3.2 core profile. Trzeba też wywalić rendering na displaylistach. Jak już wszystko będzie na współczesnym GL to myślę że dodanie współczesnego oświetlenia, cieni, ładnej wody, light blooma od lamp, może odbić, nie powinno być już dużym problemem.
Oczy mi krwawią od tego kodu, ale obecnie bawię się żeby przenieść sterowanie i tworzenie kontekstu na GLFW. Za tydzień pewnie napiszę co udało mi się zrobić.
Balaclava:
Ja proponuję przy rozbijaniu modułów oraz dodawaniu nowych pisać dla nich jakieś testy jednostkowe. Co prawda wymaga to większych nakładów pracy, ale w przyszłości ten czas spędzony na ich pisaniu zwróci się poprzez skrócenie czasu wyszukiwania bugów.
firleju:
WM_COPYDATA jest używane do multiplayera. Docelowo idzie bezpośrednio na TCP/IP.
LPT i COM muszą zostać bo są używane do sterowania pulpitami fizycznymi.
Dźwięk: czytałem i OpenAL nie jest już w zasadzie rozwijane, są też lepsze biblioteki ale mają taką wadę jak Unity, tj. można za free użyć to projektów niekomercyjnych. Licencja może się kiedyś zmienić (ale to dotyczy chyba wszystkiego).
Fonty: mnie jest obojętne, byleby dało się to normalnie ubrać w jakąś strukturę, a nie tak jak teraz że musisz ręcznie ustalać pozycję na ekranie gdzie to wyrenderować.
Co do minimum OpenGL to się nie wypowiem. Ostatnie badanie kto co ma było ze 5 lat temu. Ja mam min. 4.0 więc mnie osobiście to wsio radno.
Milek7:
--- Cytat: firleju w 11 Lutego 2017, 15:37:26 ---Dźwięk: czytałem i OpenAL nie jest już w zasadzie rozwijane, są też lepsze biblioteki ale mają taką wadę jak Unity, tj. można za free użyć to projektów niekomercyjnych.
--- Koniec cytatu ---
Opensourcowa implementacja openal wygląda na dosyć żywą: https://github.com/kcat/openal-soft
Nawigacja
[#] Następna strona
Idź do wersji pełnej