To jest stary post, ale wciąż się pojawia, więc chciałem tu dodać moje 2 centy.
Pierwsza lista danych, które powinny być przechowywane w interfejsie użytkownika / wątku wyświetlania vs wątku logicznym. W wątku interfejsu użytkownika możesz dołączyć siatkę 3D, tekstury, informacje o świetle oraz kopię danych pozycji / obrotu / kierunku.
W wątku logiki gry może być potrzebny rozmiar obiektu gry w 3D, obwiednia prymitywów (kula, sześcian), uproszczone dane siatki 3d (na przykład szczegółowe kolizje), wszystkie atrybuty wpływające na ruch / zachowanie, takie jak prędkość obiektu, współczynnik obrotu itp., a także dane pozycji / obrotu / kierunku.
Jeśli porównasz dwie listy, zobaczysz, że tylko kopia danych pozycji / obrotu / kierunku musi zostać przekazana z logiki do wątku interfejsu użytkownika. Możesz także potrzebować pewnego rodzaju identyfikatora korelacji, aby ustalić, do którego obiektu gry należą te dane.
To, jak to zrobisz, zależy od języka, z którym pracujesz. W Scali możesz używać Software Transactional Memory, w Javie / C ++ pewien rodzaj blokowania / synchronizacji. Lubię niezmienne dane, więc zwracam nowy niezmienny obiekt dla każdej aktualizacji. Jest to trochę marnowania pamięci, ale w przypadku nowoczesnych komputerów nie jest to taka wielka sprawa. Jednak jeśli chcesz zablokować udostępnione struktury danych, możesz to zrobić. Sprawdź klasę Exchanger w Javie, użycie dwóch lub więcej buforów może przyspieszyć proces.
Zanim zaczniesz udostępniać dane między wątkami, sprawdź, ile danych faktycznie musisz przekazać. Jeśli masz oktodę dzielącą przestrzeń 3d i możesz zobaczyć 5 obiektów z 10 obiektów, nawet jeśli twoja logika wymaga aktualizacji wszystkich 10, musisz przerysować tylko 5, które widzisz. Więcej informacji można znaleźć na tym blogu:
http://gameprogrammingpatterns.com/game-loop.html
Nie chodzi tu o synchronizację, ale pokazuje ona, w jaki sposób logika gry jest oddzielona od wyświetlania i jakie wyzwania należy pokonać (FPS). Mam nadzieję że to pomoże,
znak