Symulator EU07 (i nie tylko) > Na warsztacie
Planowane zmiany w exe
tmj:
--- Cytat: Milek7 w 11 Lutego 2017, 16:14:20 ---Opensourcowa implementacja openal wygląda na dosyć żywą: https://github.com/kcat/openal-soft
--- Koniec cytatu ---
Nie ma tez specjalnie w czym wybierac jesli chodzi o alternatywy. Tzn. jest WWise, ktory jest uzywany znacznie szerzej i rowniez cross-platform, ale darmowa licencja ma dosc ostre ograniczenia. Druga opcja bylby prawdopodobnie FMOD, ale tutaj tez ewentualnie moga pojawic sie ograniczenia.
edit:
--- Cytat: firleju w 11 Lutego 2017, 12:05:59 ---@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).
--- Koniec cytatu ---
Chcialbym go wprowadzic glownie po to, zeby zredukowac obecne klasy-monolity do bardziej sensownych rozmiarow. Takie rzeczy jak przekazanie sil/napiec/polaczen do sasiednich zespolow to jest wlasnie cos, co jak najbardziej mogloby sie znalezc w zespole, bo pociagowi to na nic, wiec nie ma powodu zeby tam to wpychac, a i pojazd/modul nie musi takich rzeczy robic osobiscie wiec po wyjeciu ich staje sie lzejszy. Na dluzsza mete ulatwiloby to tez synchronizacje wymiany danych miedzy elementami ktore licza fizyke, co moze sie przydac przy przejsciu na model wielowatkowy z obecnego 'kazdy wagon po kolei jeden po drugim'.
Masz calkowita racje co do rozpisania tego dokladniej, trzeba by nad tym pomyslec.
Milek7:
Są w ogóle jakieś zalecenia co do stylu kodu? PascalCase, camelCase, c_case?
firleju:
Szczerze to nie ma. Aczkolwiek większość kodu jest w PascalCase. Ja ogólnie nazwy klas i funkcji staram trzymać się w obecnej konwencji a zmienne w klasach to już róznie, ale najczęściej one są w camelCase. Zdarzają się też małe litery z podkreślnikami.
El Mecánico:
Pod kierunkiem LD:
* rozróżnić kabiny A i B w pojazdach dwukabinowych, łącznie ze wszystkimi kontrolkami elektrycznymi (nawet wyświetlacze),
* pojazdy jednokabinowe jednopulpitowe (jak SM42, SM48): przygotować do wywalenia "tylną kabinę" (jeden obiekt kabiny i jeden pulpitu, trza to rozbić),
* pojazdy jednokabinowe dwupulpitowe (jak 6Dg, ST48): zmienić podejście do obiektu jaką jest kabina i pulpit, tak, aby zmiana pulpitu była już bez ładowania czegokolwiek i resetowania jakichkolwiek zmiennych (gdyby tylko sterownik hamulca nie zwalał powietrza przy przełączaniu pulpitów, to zmianę by się nawet na biegu dało zrobić...)Dziękować:)
tmj:
Pytanie z troche innej beczki. Czy ma ktos jakies przemyslenia co do ewentualnych mozliwosci zmian/ulepszenia systemu sterowania pojazdem, z punktu widzenia uzytkownika? Konkretnie chodzi o ogarniecie istniejacych licznych skrotow, na ktore juz praktycznie zaczyna brakowac sensownych kombinacji klawiszy. Potencjalnie dwa podejscia, ktore przychodza mi na mysl to:
-- dodanie obslugi przez klikniecia na elementy bezposrednio w kabinie. Czyli np wciskamy Alt czy cos, symulator pokazuje kursor myszy i zamiast krecic glowa dookola mozemy sobie kliknac w kontrolki, przelaczajac je. Z jednej strony przydane, ale z drugiej wymagaja troche celowania, wiec moze okazac sie niewygodne.
-- dodanie czegos w rodzaju 'trybu' interfejsu, ktory zmienia funkcje klawiszy. Np. w trybie 'normalnym' pod klawiszami jest obsluga elementow uzywanych podczas jazdy (hamulce, nastawnik, czuwak itp), natomiast w trybie 'elektryka' pod klawiszami jest regulacja poszczegolnych swiatel, przyciemnienie wlaczanie ekranow itp, rozlozona bardziej intuicyjnie i bez kombinowanych skrotow w rodzaju shift+ctrl. Nie jestem pewien, czy nie byloby to jednak zbyt skomplikowane.
Jesli ktos ma lepsze pomysly, to prosze pisac :)
Nawigacja
[#] Następna strona
Idź do wersji pełnej