• Najnowsze pytania
  • Bez odpowiedzi
  • Zadaj pytanie
  • Kategorie
  • Tagi
  • Zdobyte punkty
  • Ekipa ninja
  • IRC
  • FAQ
  • Regulamin
  • Książki warte uwagi

Wydajność przy obliczaniu świata 2D

0 głosów
76 wizyt
pytanie zadane 2 listopada 2021 w C i C++ przez xsw21qaz Nowicjusz (120 p.)
Witam. Postanowiłem napisać prostą grę 2D w c++ i SFML w celach edukacyjnych. Miała to być prosta platformówka z możliwością wczytywania poziomów z plików. Świat w grze miał być podzielony na kratki, bo to chyba najprostszy sposób, by taki poziom zapisać do pliku. Udało mi się napisać wyświetlanie pojedynczych klocków, których pozycja była pobierana z pliku, oraz postać, która mogła skakać po tych klockach. Tworzenie map poprzez ręczne zapisywanie pozycji wszystkich klocków było bardzo uciążliwe, więc napisałem nawet edytor poziomów w oddzielnym projekcie. Oczywiście, w przypadku większych poziomów, obliczanie wszystkich klocków, które nawet nie znajdowały się w polu widzenia gracza było bez sensu, więc oczywistym rozwiązaniem było podzielenie mapy na sektory i obliczanie tylko tych potrzebnych.
    Po tym długim wstępie, przechodzę do mojego problemu. Podzielenie mapy na sektory wcale nie poprawia wydajności, ponieważ zaledwie 200 klocków znajdujących się w polu widzenia gracza (kratka ma bok długości 20px, a sektor 100 kratek) wyraźnie spowalnia program. Domyślam się, że powinienem łączyć klocki ze sobą i symulować je jako większe obiekty, ale dalej zastanawiam się, jak tak mała liczba elementów może sprawiać problem dla komputera. Nie chce mi się wierzyć, że obliczenie moich 200 klocków (obliczenie tylko pozycji na ekranie) wymaga więcej mocy obliczeniowej, niż wygenerowanie przestrzeni trójwymiarowej w jakiejś grze 3D, która posiada tysiące elementów.
    Optymalne połączenie klocków w większe elementy jest ciężkim zadaniem i nie wiem jak się za to zabrać. Jest to łatwe jeśli mapa jest "kwadratowa" i bez problemu można ją podzielić na prostokąty. Niestety, gdy jest ona bardziej nieregularna, nie potrafię wymyślić algorytmu, który podzieli mapę na jak największe prostokąty bez popełnienia błędu. Myślałem o tym jeszcze przed rozpoczęciem całego projektu, ale miałem nadzieję, że nie będzie problemu z obliczeniem kilkuset elementów w pobliżu gracza. A może powinienem zupełnie zmienić sposób myślenia? Jak zostało to rozwiązane w innych grach?

1 odpowiedź

+1 głos
odpowiedź 2 listopada 2021 przez adrian17 Ekspert (306,660 p.)

Nie chce mi się wierzyć, że obliczenie moich 200 klocków (obliczenie tylko pozycji na ekranie) wymaga więcej mocy obliczeniowej

No, nie powinno być. Ale to nie znaczy że musisz wymyślać nowe algorytmy łączące, tylko się zastanowić co _teraz_ możesz robić źle.

Profiler jest największym przyjacielem, oczywiście.

(jak możesz to wrzuć tutaj linka do projektu na githubie, to też bym chętnie spojrzał)

komentarz 3 listopada 2021 przez xsw21qaz Nowicjusz (120 p.)

Nie wiem co mogę robić źle. Fragment przez który program spowalnia to 3 linijki kodu - obliczenie pozycji, skali i narysowanie spritea. Chyba nie da się tego uprościć. Po prostu program spowalnia gdy jest tego za dużo. Dlatego chciałem zmniejszyć liczbę obiektów po przez połączenie. To jest chyba nieuniknione, jeśli mam walczyć o jak najwyższą wydajność. Z drugiej strony, musi być coś nie tak, skoro mój komputer lepiej radzi sobie z obliczaniem przestrzeni trójwymiarowej w jakichś grach, niż przestrzeni dwuwymiarowej w tak prostym programie, przy takiej samej, a raczej mniejszej ilości obiektów.

Mogę pokazać kod edytora. Widać w nim problem i napisałem go w jednym pliku na szybko.

https://pastebin.com/im4p9Qk1

 

komentarz 3 listopada 2021 przez adrian17 Ekspert (306,660 p.)
W sensie, już edytor jest wolny? Bo wyklikałem kilkadziesiąt kwadratów i wszystko ładnie chodzi.

W każdym razie podtrzymuję co wyżej napisałem: albo ten kod sprofiluj (a jak nie umiesz, to się naucz :D ) zamiast zgadywać, albo pokaż całość i konkretny wolny przykład. (Jak to większy projekt, to nie masz tego na GH?)
komentarz 3 listopada 2021 przez draghan VIP (105,900 p.)

Z drugiej strony, musi być coś nie tak, skoro mój komputer lepiej radzi sobie z obliczaniem przestrzeni trójwymiarowej w jakichś grach, niż przestrzeni dwuwymiarowej w tak prostym programie, przy takiej samej, a raczej mniejszej ilości obiektów.

Taka notka na boku: w grach 3d sporo obliczeń jest zrzucanych na kartę graficzną; jeśli masz relatywnie słaby procesor i wszystkie obliczenia robisz na nim, to możesz odczuwać spowolnienie.

komentarz 3 listopada 2021 przez j23 Mędrzec (169,620 p.)

@xsw21qaz, po co dałeś Sector::licznik, skoro masz Sector::vec::size?

komentarz 3 listopada 2021 przez mokrowski VIP (146,960 p.)
A z jakiego powodu rysujesz wszystkie klocki jeśli trzeba rysować tylko te które wchodzą na ekran? Rysuj te tuż poza ekranem w kierunku w którym scrollujesz tenże ekran.
komentarz 3 listopada 2021 przez adrian17 Ekspert (306,660 p.)
edycja 3 listopada 2021 przez adrian17

Nawet wtedy, jeśli jest widocznie wolne przy kilkudziesięciu/kilkuset, nawet jeśli wszystko jest renderowane, to wciąż znaczy że kod robi coś nie tak; to jest pierwsza rzecz na którą powinno się spojrzeć, nie na optymalizowanie na ślepo. (Na przykład kilka razy widywałem już kod, który w każdej klatce od nowa wczytuje wszystkie tekstury z plików)

W każdym razie podtrzymuję co wyżej napisałem: albo ten kod sprofiluj (a jak nie umiesz, to się naucz :D ) zamiast zgadywać, albo pokaż całość i konkretny wolny przykład. (Jak to większy projekt, to nie masz tego na GH?)

Podobne pytania

0 głosów
0 odpowiedzi 41 wizyt
pytanie zadane 14 grudnia 2021 w Sprzęt komputerowy przez TulismanoreV Nowicjusz (120 p.)
0 głosów
0 odpowiedzi 90 wizyt
pytanie zadane 20 lutego 2019 w Sprzęt komputerowy przez L30nn Początkujący (340 p.)

86,485 zapytań

135,241 odpowiedzi

300,487 komentarzy

57,234 pasjonatów

Motyw:

Akcja Pajacyk

Pajacyk od wielu lat dożywia dzieci. Pomóż klikając w zielony brzuszek na stronie. Dziękujemy! ♡

Oto dwie polecane książki warte uwagi. Pełną listę znajdziesz tutaj.

...