[SFML] TWORZENIE GRY: pętle, szlielet , rozdzielczość itd.

To był tylko taki przykład. W rzeczywistości przy większych zmianach nie skończyłoby się tylko na takiej jednej metodzie. Traktuj ten przykład z przymrużeniem oka bo nie warto było się rozpisywać długo o tym co mogłoby jeszcze się zmienić.

Kolizja pixel-perfect mógłbym powiedzieć śmiało jest w takim przypadku amatorska. W strzelankach 2D nie ma najmniejszej potrzeby, żeby używać kolizji pixel perfect jeśli użyjesz figur geometrycznych i przy tym wiesz co robisz.

Za bardzo uogólniasz, to już zależy od skompilowania przeciwników i mapy. Zresztą chyba wszyscy wiemy, że najlepiej użyć kolizji, która akurat pasuje do sytuacji.

Nie wątpię, że się da. Pytanie tylko jak głupim jest uzależnianie od jednego wyświetlanego obiektu całej grupy wchodzącej w skład np. naszej postaci.

Ja też bardzo zastanawiam się jakie to głupie, skoro w większości wypadków albo rysuję całą postać, albo nie.

Nie napisałem, że to rozwiązanie jest złe tylko, że jest gorsze od napisania własnej klasy. Rozważ taki przypadek. Piszesz sobie klasę uzależnioną od sf::Drawable. Po jakimś czasie twórca SFML postanawia, że przydałoby się trochę zmodernizować kod i zmienia klasę sf::Drawable w jakimś większym stopniu. Co wtedy? Musisz dostosować swoją klasę, wykonać więcej roboty niż gdybyś elementy SFML miał jako tylko część swojej klasy. Mając napisaną własną hierarchie klas, niezależną od żadnej biblioteki jedyne co musisz zmieniać jest kod źródłowy swojej klasy, sam wzorzec jest praktycznie taki sam. To samo stało się gdy Laurent (twórca SFML) wprowadził SFML 2.0 i zmienił konwencję nazywania metod i kilka innych rzeczy. Dajmy na to masz taki kod: […]

1. Całe SFML 2.x zapewnia mi stałe API wszystkich ważnych elementów, to się po prostu nie stanie w ciągu najbliższych 4-5 lat (minimum).
2. Przykład fatalny, bo nie wiem czy zauważyłeś, ale tworząc taką funkcję draw minimalizuje się ilość tych wywołań, więc kod jest krótszy a przy przejściu z SFML 1.6 na 2.0 zmiana pierwszej literki jakieś funkcji jest najmniejszym problemem. Wiesz, że w tym przeskoku doszło do zmiany prawie całej filozofii tej biblioteki?

Dlatego właśnie opakowywanie jest lepsze niż dziedziczenie - ale tak jak pisałem

Daj mi więc przykład takiego opakowania podatnego w odczuwalnie mniejszym stopniu na złamanie publicznego API, chcę to zobaczyć.

I nie rób kolizji pixel perfect dopóki naprawdę nie ma innego wyjścia.

Kombinacja kolizji prostokątów i potem ew. pikseli jest wydajna, jakiś rzeczywiście odczuwalny powód?

Wyobraź sobie, że masz powiedzmy 100 różnych obiektów (klas) które chcesz rysować, oczywiście każdy dziedziczy po sf::Drawable, w każdym masz funkcję Draw itd. Wszystko fajnie działa, ale w pewnym momencie dochodzisz do wniosku, że jednak SFML nie jest taki dobry, albo chcesz spróbować innej biblioteki albo ktoś ci kazał napisać to w innej bibliotece, albo chcesz przeportować swoją grę na inną platformę na której SFML nie działa, decydujesz się na sdl, allegro, Direcx, OpenGL, libgdx czy jakąś customową bibliotekę na dany sprzęt. I co wtedy się dzieje z twoim kodem? Ide zmian musisz wprowadzić w swoich klasach żeby podmienić bibliotekę? A teraz zastanów się ile zmian musiałbyś zrobić, jeżeli miałbyś swój moduł do grafiki w którym byłoby powiedzmy kilka klas tylko, w dodatku wszystkie mając dobrze napisany interfejs, wystarczyłoby tylko odpowiednio dopasować wywołania funkcji z biblioteki graficznej do funkcji w twoich klasach. Nie bez powodu większość firm tworzy właśnie takie swoje wrappery, nie jest to dużo pracy a daje sporą elastyczność w przyszłości. Dodatkowo możesz też się zapoznać z termem composition over inheritance.

Co do kolizji, to nie widzę żadnego powodu dla którego miałoby się stosować kolizję na pixelach, po to wprowadzono prymitywy kolizyjne żeby z nich korzystać, w większości przypadku gracz i tak nie zauważy czy pocisk który uderzył w przeciwnika zniknął dokładnie w chwili dotknięcia sprita czy jednak chwilkę wcześniej. Zresztą enkapsulacja kolizji (czyli to co napisałem wyżej tylko dot. kolizji a nie grafiki) również pozwoli ci na elastyczność przy późniejszej zmianie typu kolizji. Na początek możesz to zrobić na prostych kształtach i jak się okaże, że to cie jednak nie satysfakcjonuje to zmiana na kolizję na pixelach będzie stosunkowo prosta i szybka, ale tak jak powiedziałem, wątpię żeby ci się przydała bo shape'y powinny w zupełności wystarczyć.

Z mojej strony mogę jeszcze polecić dokumentację Enreal Engine 4, być może tam też wyczytasz jakieś fajne podejście do budowania swojego frameworka.

Wyobraź sobie, że masz powiedzmy 100 różnych obiektów (klas) które chcesz rysować, oczywiście każdy dziedziczy po sf::Drawable, w każdym masz funkcję Draw itd. Wszystko fajnie działa, ale w pewnym momencie dochodzisz do wniosku, że jednak SFML nie jest taki dobry, albo chcesz spróbować innej biblioteki albo ktoś ci kazał napisać to w innej bibliotece, albo chcesz przeportować swoją grę na inną platformę na której SFML nie działa, decydujesz się na sdl, allegro, Direcx, OpenGL, libgdx czy jakąś customową bibliotekę na dany sprzęt. I co wtedy się dzieje z twoim kodem? Ide zmian musisz wprowadzić w swoich klasach żeby podmienić bibliotekę? A teraz zastanów się ile zmian musiałbyś zrobić, jeżeli miałbyś swój moduł do grafiki w którym byłoby powiedzmy kilka klas tylko, w dodatku wszystkie mając dobrze napisany interfejs, wystarczyłoby tylko odpowiednio dopasować wywołania funkcji z biblioteki graficznej do funkcji w twoich klasach. Nie bez powodu większość firm tworzy właśnie takie swoje wrappery, nie jest to dużo pracy a daje sporą elastyczność w przyszłości. Dodatkowo możesz też się zapoznać z termem composition over inheritance.

Ekhm, dopasowań zmienionych nazw funkcji byłoby tyle samo? Zresztą pewnie dopisałbym sam klasę wirtualną Drawable i coś do jej rysowania. Poza tym przechodzenie między bibliotekami w środku dużego projektu jest… głupie? Już nawet podczas portowania prościej przeportować SFML (który po niewielkich zmianach działa prawie wszędzie) niż duży projekt oparty o jakąś bibliotekę. Chciałbym też usłyszeć jakąś konkretną zaletę takiej konstrukcji kodu nie będącą opartą o „zmienisz bibliotekę i co wtedy???”.

Co do kolizji, to nie widzę żadnego powodu dla którego miałoby się stosować kolizję na pixelach, po to wprowadzono prymitywy kolizyjne żeby z nich korzystać, w większości przypadku gracz i tak nie zauważy czy pocisk który uderzył w przeciwnika zniknął dokładnie w chwili dotknięcia sprita czy jednak chwilkę wcześniej.

Gorzej jeśli gracz zauważy, że on zginął chociaż pocisk powinien go ominąć, ale collider trochę wystawał. Albo że wróg po zabił, bo pocisk nie zareagował przez wklęsły collider. Można albo 3 godziny go dopasowywać, albo nic nie tracąc użyć kombinacji box+pixelperfect.

po to wprowadzono prymitywy kolizyjne żeby z nich korzystać

Po to wprowadzono kolizje po pikselach, żeby z nich korzystać. ;)

Zresztą enkapsulacja kolizji (czyli to co napisałem wyżej tylko dot. kolizji a nie grafiki) również pozwoli ci na elastyczność przy późniejszej zmianie typu kolizji. Na początek możesz to zrobić na prostych kształtach i jak się okaże, że to cie jednak nie satysfakcjonuje to zmiana na kolizję na pixelach będzie stosunkowo prosta i szybka, ale tak jak powiedziałem, wątpię żeby ci się przydała bo shape'y powinny w zupełności wystarczyć.

No collidery sam bym tak obsługiwał, aż takim zwolennikiem dziedziczenia nie jestem. :P Ale jeżeli piszę w SFML i mam zamiar napisać z nim cały projekt, to nie będę się bawił w zbędne uelastycznianie kodu, są sytuacje gdzie warto to zrobić a są takie gdzie nie – nigdy nie miałem przez to problemu, znajomi programiści (całych dwóch) też nie, coś robię źle?

Michał [sorry za wcześniejszą pomyłkę, pisane z telefonu] dokładnie, UE4 mimo swoich wad akurat hierarchię klas ma przyzwoitą. Właśnie korzystając z tego silnika wyciągnąłem większość wiedzy na temat struktury gier.

Przykład, który podałem nie jest fatalny. To jeden z powodów dla którego nie stosujemy dziedziczenia w takim przypadku. SFML 3.0 może wyjść nawet jutro a Ty tego nie możesz przewidzieć. Gdzie masz SFML w wersji > 1.6 ale < 2.0?
Ty jako programista pisząc kod masz myśleć o tym jak sprawić, żeby zminimalizować odwołania do czegoś co może się zmienić i od ciebie nie zależy.
Prymitywny geometryczne > PixelPerfect, koniec kropka.

coś robię źle?

Odrzucasz poprawne założenia. Jeśli dobrze napiszesz swoją grę to nawet gdyby ona miała 12847389789423 linijek to jesteś w stanie tak to zorganizować, żeby odwołania do SFML zamknęły się na np. 1000 linii, co więcej odwołania te da radę bardzo fajnie włożyć do kilku klas, które w razie potrzeby można bardzo, bardzo łatwo zmienić.
Piszesz gre z kolegami opartą na kolizji pixel perfect? No to chyba nie będzie to duży projekt.

Skoro wolisz się bawić w nieświadome, całkowite uzależnianie się od jakiejś platformy / biblioteki to dlaczego nie używasz np. GetTickCount() zamiast sf::Clock? Przecież, zawsze możesz to pozmieniać w kodzie i sie bawić całymi dniami przez to.
Jeśli użytkownik zadaje pytanie to należy mu podać najbardziej poprawną odpowiedź a nie tą, która w Twoim przypadku się sprawdziła.

Kolizja PixelPerfect? Nie. Prymitywy? Tak.
Przekazywanie sf::RenderWindow i reszty przez funkcje? Zdecydowanie nie. Singleton? Tak.
Brać pozycje z sf::Sprite? Nie. Uzależnić sprajty od własnej pozycji? Tak.
Dziedziczyć z SFML? Nie. Tworzyć opakowania dla klas SFML? Tak.

Gibas, dobrze piszesz w standardzie ale więcej powinieneś pouczyć się o grach. Poprogramuj w jakimś większym silniku to wtedy będziesz mieć pojęcie jak naprawdę powinno sie tworzyć gry.

Ten temat powinien się tak zakończyć, autor uzyskał odpowiedź a nawet małą dyskusję za i przeciw niektórym rozwiązaniom.

Dziękuje wszystkim za odpowiedz. wszystko sobie przemyślałem , i chyba wstrzymam się na razie z robieniem tamtej gry , a zamiast tego już ściąga mi się UE4, później przeglądnę kod z https://github.com/Krozark​​/SFML-book i https://github.com/chmielu24​/Tetris ,  i dopiero wtedy wrócę do gry i napisze ją tak jak mówił RazzorFlame i michal11 :P

@ RazzorFlame

Ekhm, jestem michal a nie mateczek.

mam jeszcze tylko jedno pytanie: znacie jakiś dobry , sprawdzony kurs do UE4 ?