[Visher]

56 godzin kodzenia i testów, aby osiągnąć efekt taki jak na filmiku. Jest to prosty edytor terenu w mojej gierce, której teaser możecie zobaczyć tutaj. Wcześniej tworzenie terenu odbywało się tak, jak w tym wpisie. Teraz czas robienia jednej mapy powinien się skrócić z kilkunastu godzin nudnego klikania, do kilkunastu minut żwawego przeciągania :-)

Pod maską jest sporo algorytmów i problemów matematycznych, które trzeba było rozwiązać. Do tych trudniejszych wykorzystywałem gotowe implementacje, a są następujące problemy: dekompozycja wielokątów wklęsłych na wypukłe (convex to concave, za pomocą algorytmu Marka Bayazita), triangulacja (Ear Clipping), sprawdzanie czy punkt należy do wielokąta oraz obliczanie części wspólnej dwóch wielokątów (polygon union). Większość czasu jednak zajęło wymyślanie tzw. glue code do całości oraz pomniejsze problemy, takie jak wydajność czy GUI. Powyższe algorytmy są niestety dość głupie i trzeba im dostarczyć bezproblemowe dane. A bez kilku sprytnych optymalizacji, byłaby tragedia :-P

I znowu zapraszam zainteresowanych na mojego małego discorda, niestety ostatnio odzewu nie było, a materiały (z którymi się jeszcze wstydzę) na dwa kolejne wpisy tam czekają.. ;-)

Tym czasem do zobaczenia przy następnym wpisie, a jak chcecie o coś zapytać, to walcie śmiało, tu albo na Discordzie :-)

Tag do obserwowania: #visherdev
Pozwolę sobie: #programowanie oraz #algorytmy i #matematyka
Standardowo: #gamedev #libgdx

[Narrorek]

@Visher: robi robotę!. Gratulacje!

[s.....e]

@Visher: W czym to piszesz?

[Visher]

@Narrorek: dzięki, jeszcze trochę pracy nad tym będzie, ale najtrudniejsze za mną :)
@szwe: Java + LibGDX (multiplatformowy wrapper do OpenGL na bazie Javy)

[kolnay1]

oraz obliczanie części wspólnej dwóch wielokątów (polygon union).

@Visher: w sensie intersection?

[Visher]

@kolnay1: aww mój błąd w pośpiechu :3 oczywiście chodzi o sumę wielokątów, a nie część wspólną.
@reroute: widziałem ogłoszenie w Krakowie dla programisty gamedevu, nawet z użyciem LibGDX i dojazdem w 10 minut, widełki 6-14k brutto.. to mogło być to, ale kojarzę jeszcze coś innego. A to tylko konkretnie z wykorzystaniem LibGDX, jeśli jest coś innego, co opiera się na Javie/JS, to mógłbym wziąć pod uwagę.

[Visher]

@reroute: a z moją osobą to długa historia, jestem po technikum inf. gdzie bardzo lekko zahaczyłem o Olimpiadę Informatyczną i już wtedy robiłem pierwsze gierki, teraz jeszcze zrobiłem inżyniera (Automatyka i Robotyka), więc horyzont się jeszcze bardziej poszerzył. We wszystkim jestem samoukiem, więc nie mam uporządkowanej wiedzy, ale otarłem się przy tym o tysiące tematów i nieznane aspekty potrafię dość szybko rozkminiać :-)

[kolnay1]

@Visher: jasne, sorki jeśli to brzmiało jak czepianie się, ale zastanawiałem się nad czymś konkretnym i to miało znaczenie. Mianowicie moje myśli poszły w tym kierunku, że rozwiązując tego typu problemy z wielokątami można dotrzeć nawet do topologii algebraicznej (tj. problem triangulacji można opowiedzieć językiem sympleksów i kompleksów symplicjalnych), a tym samym ułatwić sobie jakoś sumowanie i krojenie tych tworów, czy sprawdzanie czy jakiś punkt gdzieś należy. W jakim celu potrzebowałeś

[Visher]

@reroute: rozumiem, cóż, zrobiło mi się trochę cieplej i będę miał na uwadze w najbliższych miesiącach.. ;-) A mój wstyd dotyczy grafik które narysowałem, bo artysta ze mnie początkujący i jeszcze marny :-)

[Visher]

@kolnay1: nie miałem chwili, żeby dobrze odpisać :-)
Różnica jest w efekcie, co ma istotny wpływ na jakość symulacji fizyki. Mogę użyć algorytmu Ear Clipping na wielokącie wklęsłym, ale bardzo często produkuje on bardzo długie, ostre trójkąty, z cienkimi bokami. To kiepska sytuacja dla symulacji ciał sztywnych. I po prostu jakoś dziwnie to wygląda. Jeśli wcześniej zdekomponuję wielokąt wklęsły na wielokąty wypukłe, efekt wydaje się lepszy. Trójkątów natomiast zdaje się być