[Visher]

#visherdev back to #gamedev? Chyba tak, bo mam dla Was kilka rzeczy, nad którymi pracuję już od 3 miesięcy!

Ostatnio postowałem jakieś 4 lata temu (prawie zanim było to modne), po drodze wiele się zdarzyło (studia i takie tam), ale po wszystkim chyba pora wrócić na dawne tory :)

A zaczynam od rozwiązania problemów technologicznych, które ostatnim razem stanęły mi na drodze w realizacji mojej drugiej gierki. Problem dotyczył zależności między ilością FPSów, a jakością symulacji fizyki. Im gorzej radził sobie telefon z grafiką, tym gorzej zachowywała się symulacja. Dzieje się tak, ponieważ typowa główna pętla gry, to powtarzane w koło instrukcje: obliczenia(), rysuj(). Im dłużej trwa rysuj(), tym rzadziej jest wywoływane obliczenia(), a wykonanie obliczeń zależne jest od czasu. Zwiększanie ilości iteracji pozycji i prędkości w #box2d pomagało tylko do pewnego momentu.

Sprawiało to, że złożone konstrukcje w grze "rozsypywały" lub "rozjeżdżały" się. A że mój pomysł na grę opierał się na długim łańcuchu składającym się z wielu ciał połączonych przegubami obrotowymi, przy spadku FPS występował efekt "rozciągania" się łańcucha, tj. ogniwa odsuwały się do siebie i cały łańcuch sprężynował. W komentarzu wrzucam filmik z tym efektem.

Rozwiązanie? Chwilę zajęło jego zaimplementowanie, ale całkowicie uniezależniłem obliczenia fizyki od renderowania grafiki. Działają cały czas dwa wątki, które robią jednocześnie jedno i drugie. Około 60 razy na sekundę potrzebna jest tylko synchronizacja, która trwa ułamek sekundy i tworzy kopię świata gry na potrzeby wątku z rysowaniem. Teraz mogę mieć obliczenia nawet i 10 000 razy na sekundę, jeśli tylko zechcę :-)

W poniższym benchmarku zestawiłem prostą symulację sztywnego mostu wiszącego, czyli najgorszego scenariusza, jaki udało mi się wymyślić. Jakbym chciał zrobić uginający się most wiszący, to użyłbym sprężynujących przegubów, a nie liczył na to ile FPSów będzie miał użytkownik :-) W pierwszym przypadku symulacja tak się rozjeżdża, że kulki przelatują pomiędzy mostem.

Cóż, to tyle na dziś, największe zmiany zaszły na razie pod maską, trochę ponad 5k linii kodu czegoś w rodzaju własnego silnika do gier na bazie #libgdx - pure Java. W kolejnych wpisach będzie o skalowalności grafik i dostosowywaniu pod różne rozdzielczości (będzie pixel-perfect dla niemal każdej rozdzielczości!), samej grze którą robię i zmianach w grafice, które wykonałem - teraz są jakieś stare, rozpikselizowane :)

Zostawcie subskrypcję na #visherdev, postaram się pisać co tydzień :)

#androiddev i na początek pozwolę sobie #gry #programowanie

[Visher]

@Visher: zachowanie łańcucha..

[Visher]

@Visher: i duży gif z pierwszego posta

[Jebiasz]

@Visher: jak dla osoby zupełnie niezwiązanej z programowaniem, ale jarającej sie grami wideo temat dość ciekawy, będę obserwował tag. Dzięki!

[f.....6]

@Visher: mam dziwny dysonans, z jednej strony symulacja wygląda całkiem ogarnięcie, ale z drugiej opisywane przez ciebie rozdzielenie symulacji od prezentacji to absolutne podstawy podstaw, rzecz elementarna i niezbędna. Że nie wspomnę o nazwach funkcji po polsku...

[Visher]

@frogi16: Spokojnie kolego, ja tak piszę, żeby zaciekawić wszystkich i aby wszyscy zrozumieli :-) Kod piszę normalnie, po angielsku. Wiem do jakich problemów prowadzi pisanie kodu w języku, gdzie trzeba odmieniać rzeczowniki przez przypadki, czy uwzględnić inne aspekty naszego ojczystego języka :D A co do trywialności zagadnienia - to prawda, aczkolwiek wymaga to samodzielnego zaimplementowania, dlatego się pochwaliłem. Hobbystyczny gamedev raczej nie często to robi, bo mnóstwo rzeczy działa dobrze