STL do gier, tak czy nie? [Zamknięte]


144

Każdy język programowania ma swoją standardową bibliotekę kontenerów, algorytmów i innych przydatnych rzeczy. W przypadku języków takich jak C #, Java i Python korzystanie z języka bez jego standardowej biblioteki jest praktycznie nie do pomyślenia .

Jednak w wielu grach w C ++, nad którymi pracowałem, albo wcale nie używaliśmy STL, używaliśmy niewielkiej jego części, albo korzystaliśmy z własnej implementacji. Trudno powiedzieć, czy była to słuszna decyzja dla naszych gier, czy po prostu z powodu nieznajomości STL.

Więc ... czy STL dobrze pasuje, czy nie?



1
Tak, to był ten, który miałem na myśli „wykorzystaliśmy własną implementację”. :)
hojny

3
Jeśli masz możliwość zlokalizowania i zakupu klejnotów programistycznych Best of Game, zrób to. Istnieje tytuł artykułu „Korzystanie z STL w programowaniu gier” Jamesa Boera, ArenaNet, w którym naprawdę dobrze wykorzystuje STL.
chiguire,

Właściwie używanie Java bez standardowej biblioteki jest całkiem możliwe, nazywa się J2ME: p
Bart van Heukelom

1
Świetne pytanie!
Alan

Odpowiedzi:


191

Kiedy pracowałem nad profesjonalnym tworzeniem gier, STL był zbyt niedojrzały i nadęty. Ale to było> 10 lat temu.

Teraz pracuję w symulacji wojskowej, która ma jeszcze surowsze wymagania dotyczące wydajności (np. Liczba klatek na sekundę nigdy nie spadnie poniżej niektórych FPS). W symulacji wojskowej STL jest używany wszędzie.

Niektórzy ludzie, którzy mówią ci, aby nie używać STL, argumentują, że nie zawsze jest to idealne lub nawet najlepsze rozwiązanie problemu. Ale to nie jest odpowiedź na pytanie. Pytanie powinno brzmieć: Czy jest coś z natury złego w używaniu STL w grach? Powiedziałbym, że nie, STL jest w większości przypadków lepszą implementacją niż to, co wymyśliłby użytkownik na własną rękę.

Po prostu upewnij się, że wiesz, jak korzystać z STL i używać go w swojej grze. Przeczytaj kilka książek i spójrz na kod implementacyjny w STL, którego używasz.


49
To całkiem solidna rada. Mem „STL jest wolny” nie był prawdziwy przez co najmniej pięć lat i prawdopodobnie znacznie dłużej. Będzie nadal działał, podobnie jak nonsens „Java is slow” i „.NET is slow”, dopóki nie stanie się jasne dla wszystkich, że już tak nie jest. STL pomaga pisać lepsze programy; Posunąłbym się nawet do stwierdzenia, że ​​nieużywanie go w większości przypadków (poza tym gdzieś 0,1%) jest nieodpowiedzialne. (Twierdzenia, że ​​nie pasuje do danej domeny problemowej, są często bardziej oskarżeniem o sposób rozwiązania problemu, a nie samą STL. Napraw swój kod, ludzie.)
Ed Ropple

5
@Ed Ropple: Myślę, że problem nie polega na tym, że STL nie pasuje do danego problemu, problem polega na tym, że pasuje do zbyt wielu problemów, co powoduje, że kod w nim jest zbyt skomplikowany. Przerażające jest to, że ludzie nadmiernie używają STL i myślę, że jest to jedna z przyczyn, dla których tak wielu (w tym ja) w ogóle z niego nie korzysta. Tak jak w jednym z przykładów, które widziałem nie tak dawno temu, gdzie pytaniem było, jak uzyskać największą z 3 liczb, jedną z odpowiedzi było popchnięcie ich do std :: vector, a następnie std: sortuj. To zdecydowanie wymusza rozwiązanie niepotrzebnego na bardzo prosty problem.
Simon

22
@ Simon: z całym szacunkiem ostatni przykład jest oznaką skrajnego braku wiedzy i nie ma nic wspólnego z STL ... ta osoba zrobiłaby to samo w każdym innym języku z listami, które można sortować. To jego myślenie jest zepsute.
ggambett

@EdRopple próbuje wdrożyć analizator składni STL dla plików obrazów PPM (łącznie mniej niż 100 linii kodu, jeśli tylko celuje w P6 lub P3). Połowa wynikowego kodu służy tylko do pominięcia linii komentarza, ponieważ STL nie zapewnia czegoś takiegoif(stream.nextCharacter() == '#') stream.skipLine();
GameDeveloper

@DarioOO Nie znam tego formatu pliku, ale do tego właśnie służą adaptery i filtry strumieniowe. Napisałem ten komentarz pięć lat temu, umysł (i od czasu do czasu wraca!), Ale teraz piszę o wszystkim, co nie jest super, super-krytyczne w funkcjonalnym stylu opartym na transformacji i problemach takich jak ten, który opisują wypadnięcie problemu. Tak naprawdę nie dbam tak bardzo o liczbę wierszy (i IMO, ani nie powinieneś), dbam o poprawność implementacji, potem przejrzystość, wydajność, a potem takie rzeczy jak długość kodu.
Ed Ropple,

63

Powiedziałbym, że z góry mojej głowy lepiej jest używać STL, chyba że wiesz dokładnie, dlaczego nie chcesz go używać.

Oto kwestia STL: jest rozwijana przez ludzi mądrzejszych od ciebie. To nie ma być obraźliwe ani nic innego, po prostu STL jest rozwijany przez ludzi, których praca polega na budowaniu STL. Będzie on praktycznie tak szybki, jak pozwala na to platforma, i będzie ogólnie znacznie bardziej niezawodny niż rozwiązanie domowej roboty (i powinno to być równie ważne, jeśli nie martwisz się o czystą szybkość - ponieważ Twoja gra potrzebuje solidność nieco większa niż potrzebujesz prędkości; ta druga nie ma znaczenia bez pierwszej).

Skargi, że STL wymusza „wąskie spojrzenie na świat”, wydają mi się trochę głupie. To są pojemniki. Mają ograniczony zestaw operacji, ponieważ kontenery mają ograniczony zestaw operacji. Co robisz, że się z tym nie kręci?


4
Nie sądzę, aby ktokolwiek musiał uzasadniać, dlaczego nie powinien używać STL. Nie zgadzaj się też z całym argumentem „używaj go, bo są mądrzejsi od ciebie”. STL został zaprojektowany wokół konkretnego widzenia domeny problem, nie tylko pojemniki tj algorytmów podzielników, iteratory, cechy itd. To na tyle w porządku, ale nie jest to jedyny sposób patrzenia na tej domenie problemu
zebrabox

2
Więc wolisz kod wypuszczany od domu niż ogólnie testowany, mocno solidny kod? Domena problemowa nie różni się tak bardzo od projektu do projektu (oprócz być może projektów osadzonych - nawet konsole mają teraz przyzwoite implementacje STL!). Niezależnie od gry, twój problem po prostu nie jest inny, a jeśli robisz coś, co zamierzasz wysłać, masz domyślną odpowiedzialność za napisanie solidnego kodu. Czy ponowne zamontowanie koła doprowadzi do lepszej wytrzymałości i elastyczności? Skłaniam się ku „nie”. To, że nie jest to „jedyny sposób”, nie oznacza, że ​​nie jest ogólnie lepsze.
Ed Ropple,

20
Powiedziałbym, że gamedev polega na tworzeniu gier , ale OK. Jeśli twoje założenia są tak słabe, że zaczynasz ćwiczyć tego rodzaju alokację zasobów, to tak, musisz cofnąć się i ponownie je ocenić. Ale możesz tworzyć niesamowicie szybkie aplikacje, które równie dobrze używają STL - a na pewno dowolną inną implementację - kiedy naprawdę wiesz, co robisz . Dowiedz się, co robisz> kultywowanie ładunków - odmowa STL. Nikt nie powiedział, że STL jest zawsze najlepszą odpowiedzią. Mówię tylko, że jeśli nie potrafisz wyjaśnić, dlaczego nie jest to najlepszy kurs , powinieneś używać STL.
Ed Ropple,

11
Nie wydaje mi się, żeby to było prowokujące - zostało sformułowane w taki sposób, aby utrwalić czyjąś pamięć, ale jest to niezwykle konserwatywne i proste podejście. Krótko mówiąc: ludzie, którzy opracowują STL, są bardziej kompetentni i lepiej wyposażeni niż ktoś, kto uzna, że ​​musi zadać to pytanie. Jeśli musisz zapytać kogoś innego, czy STL jest odpowiedni, czy nie, prawie na pewno nie masz wiedzy na temat konkretnej dziedziny, aby odpowiednio przygotować domowe rozwiązanie.
Ed Ropple,

4
„Będzie to tak szybko, jak tylko platforma może na to pozwolić”. Jest to ostateczna nieprawda, ponieważ wielu producentów kompilatorów nie może zadać sobie trudu, aby przepisać STL, tak aby rzeczywiście wyciskał największą wydajność z konkretnej architektury. STL nie ma żadnej gwarancji na charakterystykę wydajności, z wyjątkiem dużego O. O może jednak być tak wydajne lub nieefektywne, jak chce tego producent kompilatora.
Kaj

35

Widziałem bardzo niewiele powodów, aby nie używać STL do gier.

W przypadku problemów z alokacją pamięci wiele osób nie wie o tym, ale możesz napisać niestandardowe alokatory dla swoich klas kontenerów STL. Alokatory to w zasadzie klasy zasad, które przekazujesz do szablonów, aby określić sposób wykonywania alokacji. Korzystając z nich, zwykle możesz obejść wszelkie problemy z pamięcią, które są problematyczne na wybranej platformie.

Oczywiście, jeśli używasz STL i robisz głupie rzeczy, takie jak mapy ciągów znaków do dużych typów, które nie są wskaźnikami, masz większe problemy.


w rzeczywistości użycie dużych typów innych niż wskaźniki w mapie jest dobrym przykładem użycia, ponieważ mapy stdlib wymagają nie unieważniania iteratorów, co zmusza implementację do użycia wskaźników i indywidualnie przypisanych elementów odwzorowanych. Najlepszym rozwiązaniem dla gier jest używanie google::sparse_maplub pisanie własnych.
v.oddou

dlaczego nie gęsta mapa?
GameDeveloper

23

Domyślna STL ma sporo problemów, które utrudniają korzystanie z niej, szczególnie jeśli chodzi o wyrównanie pamięci.

Dostosowany wariant, taki jak EA STL, jest specjalnie zaprojektowany do gier i może zapewnić znacznie lepszą wydajność pamięci i użyteczność konsoli. Stało się open source w 2016 roku, zgodnie z klauzulą ​​BSD-3, z repozytorium na GitHub .


19
Problemy z wykorzystaniem pamięci i gier STL można zwykle rozwiązać za pomocą niestandardowych klas alokatora. Rzeczywiście, w mojej poprzedniej pracy nasza „niestandardowa” klasa wektorów była tylko cienkim opakowaniem, std::vectorktóre przesłoniło domyślny alokator.
Blair Holloway,

1
@Blair Holloway: „Niestandardowe alokatory są oparte na klasach, a nie na instancjach. Alokatory są wymagane do konstruowania i niszczenia obiektów, a także alokacji. Wymusza to połączenie dwóch oddzielnych koncepcji: alokacji i konstrukcji. To tylko niektóre z problemy z przydziałami stl, niestety. ” EA STL podaje kilka innych ważnych powodów, dla których alokatory STD są złe. Nie chodzi tylko o to, czy mogą zostać zastąpione.
Simon

@ Simon - nie będę twierdził, że system alokacji STL jest doskonały, ponieważ tak nie jest. Znalezienie odpowiedniego rozwiązania zajęło nam dużo czasu. Co ja mówię, jest to, że w niektórych przypadkach, to jest możliwe, aby uzyskać realne, Gra w obsłudze rozwiązanie przy użyciu STL i trochę pracy z niestandardowymi podzielników.
Blair Holloway,

@ Simon - Aby rozwinąć: chociaż STL może być kłopotliwy, jest to bardzo dobrze przetestowany i wolny od błędów fragment kodu; jeśli możesz go użyć, zaoszczędzisz roboczogodzin na debugowaniu niestandardowego rozwiązania. Moja obecna praca omija STL na korzyść domowych dystrybutorów i musiałem spędzać czas na debugowaniu i refaktoryzacji części tego kodu, ponieważ nie jest on na tym samym poziomie dojrzałości co STL.
Blair Holloway,

1
@ Simon: Jestem trochę spóźniony na imprezę tutaj, ale jestem ciekawy, czy podałbyś konkretny przykład tego, co masz na myśli. Jaki jest dobry przykład rozwiązania konkretnego problemu w taki sposób, że STL jest zbyt ogólny, aby go skutecznie rozwiązać?
BRaffle,

21

Oto co Mike Acton (Dyrektor silnika Insomniac Games z Spyro the Dragon, Ratchet & Clank oraz Resistance sławy) miał do powiedzenia na temat tego, kiedy zapytałem tutaj . Zauważ, że zapytano go zarówno o STL, jak i ogólnie Boost w związku z użyciem go w grze.

STL / Boost, czy należy do gamedev? Jeśli tylko części, które?

Pytasz o dwie różne rzeczy, prawda? STL i Boost, osobno. Ale tak naprawdę moja odpowiedź jest taka sama: nie ma w tym nic złego , ale odradzam ich użycie. Zastosowanie obu zachęca ludzi do dopasowania rozwiązania problemu zamiast do znalezienia rozwiązania problemu. Rozwiązanie powinno zawsze być odpowiednie dla dostępnych danych i ograniczeń sprzętowych itp. Zarówno STL, jak i Boost mają bardzo wąski obraz „świata”, a ich właściwe wykorzystanie jest ograniczone. Naprawdę zniechęcam ich, ponieważ od razu prowadzą programistów w złym kierunku. Często mówię, że jeśli czujesz, że potrzebujesz jednego z nich, prawdopodobnie nie rozumiesz problemu, że „

Zauważyłem również, że większość profesjonalnych twórców gier dąży bardziej do C niż C ++.


18
Nie zgadzam się na dążenie bardziej do C. Zdecydowana większość twórców gier oraz autorów SDK używa C ++. W rzeczywistości ostatnim głównym użytkownikiem C był id, a nawet Carmack przeszedł teraz do C ++ ...
Goz

82
Komentarz pana Actona wydaje się szkicowy. Ogólnie rzecz biorąc, STL dobrze pasuje do tych problemów. Jeśli próbujesz zrobić coś w taki sposób, że podejście STL wydaje się „złe”, prawdopodobnie dobrym pomysłem jest ponowna ocena twojego podejścia i sprawdzenie, czy rzeczywiście robisz to mądrze. Z mojego doświadczenia wynika, że ​​prawdopodobnie nie jesteś. (IMO jest znacznie mądrzejszy, aby rozwiązać problem, silnie rozumiejąc go w kontekście twoich narzędzi, niż wyrzucać narzędzia tylko po to, aby wykonać je od nowa.)
Ed Ropple

50
Moje doświadczenia ze STL są prawie przeciwne. Jest wydajny i oszczędza czas. Jeśli czujesz potrzebę rozwijania własnej biblioteki szablonów lub biblioteki kontenerów, to w porządku. Ale nie udawaj, że STL (lub boost, jeśli o to chodzi) jest zły. Używam STL intensywnie na komercyjnych telefonach iPhone, Nintendo DS, Wii, PC, Mac i Xbox. Za każdym razem, gdy zmuszano mnie do korzystania z czyjejś „lepszej” biblioteki, okazało się, że brakuje jej i zawiera błędy.
BRaffle,

5
Działa tak dobrze na DS, jak na każdej innej platformie, na której go używałem. Użyłem STL w całym interfejsie użytkownika i kodzie AI. Gra była ds.ign.com/articles/832/832147p1.html . Pracowałem w małym studiu, które było częścią Amaze, która była częścią Fundacji 9.
BRaffle

7
Mike zajmuje się danymi. Analiza danych sugeruje najlepszą metodę transformacji danych. Zastosuj na dużą skalę i masz programowanie. W tym kontekście jego krytyka ma wiele sensu. STL (i wzorce projektowe) sugerują, że zamiast badać dane w celu znalezienia rozwiązania, badamy rozwiązania w naszej torbie sztuczek, aby znaleźć takie, które działa z danymi. Nie zamierzam mówić w imieniu Mike'a, ale wierzę, że sugerowałby, że ten sposób podejścia do problemu jest odwrotny i może potencjalnie prowadzić do nieefektywnych lub rozdętych rozwiązań.
Dan Olson

19

Jeśli z jakiegoś powodu przepisujesz coś, co już istnieje w STL, przestań . Użyj STL.

STL został zoptymalizowany przez lata analizy i czasu, i jest to bezpieczny zakład, że prawdopodobnie nie zamierzasz napisać czegoś bardziej wydajnego. Nie oznacza to, że powinieneś używać STL tam, gdzie możliwe jest prostsze rozwiązanie (tj. Użyć tablicy, gdy masz znaną ilość rzeczy, a nie stl :: list), ale jeśli piszesz własną implementację mapy ( podstawowa struktura danych, a nie mapa świata), robisz to źle.


7
map <> prawie nigdy nie jest tym, czego chcesz używać do wydajnej pamięci lub procesora w kontekście gry. hash_map <> jest prawie zawsze lepszym wyborem, chociaż wydajność hash_map znacznie różni się w zależności od dostawcy. Jeśli budujesz grę na konsolę lub ze skalowalną grą sieciową, STL może być absolutnie zbyt wolne lub nadęte dla twoich celów.
Ben Zeigler

3
unordered_map <> jest teraz szeroko dostępny i ma wyjątkowo surowe wymagania dotyczące wydajności w bieżącym projekcie TR1. (Wydaje mi się, że do przesadnej specyfikacji - nawet zabrania otwartego haszowania, i chociaż jest to zwykle wolniejsze, nie sądzę, że powinno być to zabronione przez standard).

5
STL oferuje algorytmy oraz kontenery. Nigdy nie ma powodu, aby nie używać wersji stl algorytmu. Na przykład na std::sortogół używa introsortu pod spodem, niezwykle szybkiego i na tyle złożonego, że nie będziesz chciał tego zrobić sam.
deft_code

prawda jest unordered_mapalbo w C ++ 11, albo oba są zbyt wolne, to, czego chcesz, to otwarta mapa mieszająca, taka jak google :: sparse_map lub twoja.
v.oddou

16

Czy STL nadaje się do gier? Zdecydowanie. Gry to złożone oprogramowanie, STL zapewnia funkcje pomagające zarządzać złożonością, więc jest dobrze.

Czy dobrze pasuje do twojej platformy? Niekoniecznie. Jeśli piszesz dla konsoli, musisz bardzo uważać na użycie pamięci i pamięci podręcznej. STL nie ułatwia tego.

Myślę, że zbyt często mylimy „gry” z „wysokowydajnymi grami czasu rzeczywistego, które działają na wbudowanym lub niestandardowym sprzęcie”, ale ważne jest, aby wprowadzić rozróżnienie. Jeśli piszesz grę systemu Windows, która nie próbuje działać w trybie pełnoekranowym ze stałą prędkością 60 klatek na sekundę, nie ma powodu, aby unikać narzędzi udostępnianych przez standardową bibliotekę.


10

Wiem, że na przyjęcie jest już późno, ale zmiany czasu i odpowiedzi pozostają w pobliżu. C ++ 11 ma dość duże zmiany, z których wiele ma na celu zwiększenie wydajności C ++ i biblioteki standardowej. Wygląda na to, że ci, którzy nie używają STL lub Boost, również nie nadążają za nowymi standardami, pozostawiając rozwiązania domowe bez istotnych ulepszeń, oczywiście nie zawsze tak jest.

Użyłem STL do każdego projektu od połowy lat 90. do dziś, z wyjątkiem krótkiego czasu w EA. Myślę, że strona anty-STL miała jakieś racjonalnie uzasadnione powody, aby jej nie używać. Te w dużej mierze zniknęły. Niestandardowe alokatory to jedno rozwiązanie, użycie rezerwy to drugie, a nieprzekazywanie wartości po wartości to trzecie, ale są one dość proste i każdy programista powinien je znać. Ważniejsze jest jednak użycie algorytmów. Autorzy kompilatorów dokładnie wiedzą, co robi funkcja for_each () i mogą zoptymalizować kod. Nie może się to zdarzyć w przypadku pętli domowej. For_each () na obiekcie const jest jeszcze lepszy. Microsoft optymalizuje for_each na wiele sposobów, w tym serializacji. Mają także bibliotekę AMP, która ma parallel_for_each (). Jeśli masz szansę, porozmawiaj o tym z inżynierami kompilatorów. Kompilatory konsoli zoptymalizują to, co zostanie wykorzystane, więc „ trochę problemu z jajkiem i kurczakiem. Microsoft idzie bardzo ciężko z C ++ 11 i następny XBox nie będzie inaczej. Nie mam pojęcia o PS4, jeszcze go nie mamy.

Niestandardowe alokatory to jeden ze sposobów radzenia sobie z problemem z pamięcią, ale inną (często pomijaną) opcją jest użycie nowej i usunięcia na podstawie klasy. W ten sposób można uzyskać ogromny wzrost wydajności.

Pogląd, że Boost i STL mają wąski pogląd na rozwiązywanie problemów, jest czystym szaleństwem. Jestem zaskoczony, jak wiele rzeczy w STL i Boost można dostosowywać za pomocą cech i zasad. Wyszukaj ciąg znaków niezależny od wielkości liter jako przykład.

Jeśli chodzi o długi czas połączenia i rozdęcie kodu, nowy szablon zewnętrzny powinien w tym pomóc. Generalnie uważam, że długie czasy kompilacji wynikają z nadmiernego sprzężenia i niewłaściwego użycia pch.

Najbardziej przekonującym powodem używania STL w porównaniu z samodziałem jest to, że są miliony ludzi, którzy mogą ci pomóc z STL. Jak zawsze, nie optymalizuj przedwcześnie i testuj, testuj, testuj.


ciekawe pomysły; co rozumiesz przez „ użyj nowego i usuń na podstawie klasy ”? Masz na myśli, przyspieszyć proces, używając obiektów już na stercie?
johnbakers

9

To gorący temat w tworzeniu gier. Ja osobiście tego nie polecam, z wyjątkiem być może EASTL, jak wspomniano powyżej. Mam dwa główne problemy ze STL (technicznie „Standardowa biblioteka C ++”, ponieważ STL nie jest już nazwą) w grach. 1) Dynamiczny przydział pamięci często marnuje dużo czasu działania w grach, gdy używany jest STL. 2) Wykorzystanie STL zachęca do podejścia do architektury gier z wykorzystaniem szeregu struktur, podczas gdy podejście do struktur jest znacznie bardziej przyjazne dla pamięci podręcznej.


Jak wspomniano w innym miejscu, możesz przypisać niestandardowe alokatory do klas kontenerów - w razie potrzeby możesz użyć list swobodnych (tablice wstępnie przydzielone). Tablica struktur zamiast struktury tablic jest bardzo zależna od tego, co próbujesz zrobić - nie ma twardej i szybkiej reguły, która z nich jest lepsza.
Skizz

Doceniam twoją opinię, że ważne jest, aby dobrze zrozumieć problem, który rozwiązujesz. Ale z szacunkiem nadal uważam, że nie zgadzam się z pańskim wnioskiem. Każdy problem ma wzorce użytkowania, których nie można wyrazić niestandardowym alokatorom STL, ale można je łatwo wykorzystać w niestandardowym kontenerze, takim jak alokator o stałym bloku zaimplementowany z płaską tablicą. A zastosowanie stałej transformacji w szeregu homogenicznych typów najprawdopodobniej spowoduje znacznie lepszą spójność pamięci podręcznej niż iteracja po wektorze typów polimorficznych i wywołanie metod wirtualnych.
Terrance Cohen

5

To zależy. Jak duży jest projekt, jakie platformy i jaka jest oś czasu?

Jeśli pracujesz nad dużym projektem, na platformach z ograniczonymi zasobami, ze znaczną osią czasu i budżetem, możesz zaoszczędzić sobie wiele kłopotów, unikając nieuchronnego piekła, które będzie patrzeć na pół miliona kodów kreskowych, które są zaśmiecony STL, nie może utrzymać liczby klatek na sekundę powyżej 30, zjada wystarczającą ilość pamięci RAM, aby zmieścić kilka dodatkowych zasobów i zajmuje 2 godziny.

W innych sytuacjach jednak STL, a nawet Boost mogą być bardzo przydatne, gdy są odpowiednio stosowane. Pracowałem nad tytułami, które wykorzystywały wybór STL / Boost i były absolutnym marzeniem do kodowania: mniej błędów / wycieków i łatwy w utrzymaniu kod oznacza więcej czasu na zabawę nowych funkcji! Szczególnie w przypadku projektów hobbystycznych jest to ogromna wygrana w dziale motywacji.

Wiedz, kiedy wymieniać wyniki dla wygody!


1
„Wiedzieć, kiedy wymieniać wyniki dla wygody”. Tak. Samo zdanie jest równie dobrą odpowiedzią jak każde inne. Dowiedz się, co musisz osiągnąć w swojej grze, skonsultuj się z rówieśnikami i zdecyduj, czy STL pomoże ci się tam dostać, czy przeszkodzi. Powiedziałbym, że jeśli nie chcesz stawiać poprzeczki w grafice i wydajności nowej generacji w swojej grze, STL prawdopodobnie Ci pomoże.
gkimsey,

4

IMHO Powiedziałbym, że jest dobrze dopasowany, ponieważ STL już działa dobrze i jest zoptymalizowany do zadań, do których został stworzony. Poza tym pracujesz nad grą, więc skorzystaj z dostępnych narzędzi, które ułatwią Ci życie, a Twój kod będzie mniej podatny na błędy.

Po co zawracać sobie głowę odkrywaniem koła, kiedy możesz pracować nad czymś innym, jak sztuczna inteligencja gry, wrażenia użytkownika lub jeszcze lepsze; testowanie i debugowanie?


2
W praktyce pod koniec projektu wydajność wydaje się być krytycznym problemem. Jeśli korzystasz z STL, masz bardzo mało możliwości optymalizacji, ponieważ bierze on określone aplikacje i rozwiązuje je w ogólny sposób. Rozwiązywanie konkretnych przypadków w określony sposób (i bez dynamicznej alokacji pamięci) prawie zawsze ma wyższą wydajność.
Terrance Cohen

2
Ale jeśli nie chcesz dynamicznej alokacji pamięci, nie powinieneś używać STL. Właśnie o to chodzi. Twój własny kod nie będzie lepszy, a na pewno może być gorzej. Decyzja projektowa nadużywać STL jest problem tutaj, a nie STL, jego możliwości, lub jego cechy perf. Atakujesz niewłaściwą część problemu.
Ed Ropple,

4

STL jest absolutnie w porządku do użytku w grach, o ile dobrze go rozumiesz. Nasz silnik korzysta z niego dość szeroko i nigdy nie stanowiło to problemu. Nie mam doświadczenia w tworzeniu konsoli, co może być zupełnie inną historią, ale jest dobrze obsługiwane na wszystkich platformach PC (Windows / Mac / Linux).

Najważniejsze jest zrozumienie, jakie są mocne i słabe strony każdego rodzaju pojemnika i wybranie odpowiedniego pojemnika do wykonywanej pracy.


4

Mój były pracodawca przeszedł z używania solidnego zestawu niestandardowych klas kontenerów na STL. Czas kompilacji wzrósł i zmniejszyła się łatwość debugowania, oba dość znacząco. Gdybyśmy zaczynali od zera, STL (być może lepiej użyty) prawdopodobnie miałby sens, ale nigdy nie było dla mnie jasne, że przestawiliśmy się na STL, co uzasadniałoby wyrzucenie działającego, szybkiego, debugowalnego kodu.

W przypadku moich osobistych projektów to, czy STL pasuje, czy nie, zależy od projektu. Jeśli próbuję wykonać pewne prace zoptymalizowane pod kątem danych, zoptymalizowane pod kątem dostępu do pamięci i pamięci podręcznej w stylu Mike'a Actona, przynajmniej pomyślę o rozwinięciu własnych niestandardowych struktur danych. Jeśli prototypuję jakieś algorytmy lub rozgrywkę i nie dbam o wydajność, skalowalność, platformę docelową itp., Automatycznie zdobędę STL.


4

Moim 2 centami jest to, że STL działa dobrze. Opracowuję silnik gry 3D (nie jakości AAA, ale wystarczająco zaawansowany - skrypty typów jednostek, odroczony renderer, zintegrowana fizyka Bullet) na PC i nie widziałem, aby kontenery stały się głównym wąskim gardłem. Nieprawidłowe użycie 3D API i słabe algorytmy były najlepszymi celami (ustalonymi przez profilowanie!) Za każdym razem, gdy wchodziłem i próbowałem uzyskać nieco większą wydajność.


3

Zbudowałem gry przy użyciu STL i podoba mi się to, i wydaje się, że działa dobrze.


3

Dobre pytanie! Bardziej szczegółowe pytanie brzmi: jakie są niektóre typowe wymagania gry, których nie można spełnić za pomocą STL i Boost.

Z mojego doświadczenia wynika, że ​​ścisłe ograniczenia pamięciowe sprzętu konsoli sprawiają, że każdy kontener o dynamicznej wielkości jest złym pomysłem, niezależnie od tego, jak sprytny jest twój niestandardowy alokator. Kontenery, które nie mają umyślnych granic, zachęcają programistów do pisania kodu, który nie ogranicza granic ich zestawów danych. W zależności od niezliczonych zmiennych, które są trudne do śledzenia, możesz przekroczyć ograniczenia pamięci. Mam przeczucie, że jest to jedna z głównych przyczyn niestabilności we współczesnych grach.

Dodatkowo, nadużywanie szablonów może prowadzić do bardzo długich czasów kompilacji w dużej bazie kodu i spowoduje powiększenie rozmiaru pliku wykonywalnego, aby nie mieścił się już w pamięci podręcznej, powiedzmy, pomocniczego rdzenia na ps3.

Jednak w przypadku projektowania wyłącznie na komputery PC STL i Boost są bardzo dobre. Chociaż ogólne rozwiązania nie zawsze są idealne, często są wystarczająco dobre. Twoje pierwsze rozwiązanie problemu prawie nigdy nie jest idealne i poprawiasz lub zastępujesz niedoskonałości, dopóki nie będą wystarczająco dobre.


2

STL dobrze pasuje do twojej gry, jeśli STL dobrze pasuje do twojej gry.

Podobnie jak w przypadku wszystkich wyborów technologicznych dokonywanych podczas programowania, musisz rozważyć zalety i wady - czy stworzenie własnej biblioteki zapewni mi bardziej korzystne wykorzystanie pamięci, wydajność i produktywność niż zwykłe korzystanie z STL? Możliwie; chociaż równie łatwo jest stworzyć vectorimplementację, która zużywa więcej pamięci, jest wolniejsza i wymaga dużej konserwacji, aby zachować funkcjonalność w porównaniu z tym, co już istnieje.

Ludzie nie powinni unikać używania STL w swoich grach, ponieważ inni ludzie unikają używania STL w grach; powinni unikać korzystania z niego, jeśli rozważą wszystkie swoje opcje i naprawdę wierzą, że kolejne wdrożenie poprawi jakość ich produktu.


2
Zgadzam się w 100% z ostatnią częścią twojego komentarza, ale pójdę jeszcze dalej: jeśli możesz jednoznacznie wykazać, dlaczego STL nie jest dobrą opcją, nie używaj STL. W przeciwnym razie zrób. Kult cargo (wszystko od „och, twórcy gier używają C ++!” Do „och, twórcy gier nie używają STL!”) Jest niezdrowy. Chciałbym jednak trochę poradzić sobie z twoim drugim akapitem: jest mało prawdopodobne, że ludzie, którzy są na tyle naiwni, by myśleć, że ponowne wdrożenie STL to dobry pomysł, zbudują coś lepszego vectorniż ludzie STL. Zanim to zrobisz, nie będziesz już myśleć, że musisz! :-)
Ed Ropple,

2

Jak w przypadku większości pytań, odpowiedź nigdy nie brzmi „tak czy nie”, czarny lub biały. STL dobrze pasuje do niektórych problemów, używanie go do tych problemów powinno być w porządku. Błędem jest zakładanie, że jest bezużyteczny, ale błędem jest również zakładanie, że właściwe jest stosowanie go w każdej sytuacji.

Największym problemem, na który należy zwrócić uwagę podczas korzystania z STL podczas tworzenia gier, jest przydzielanie pamięci. Domyślne alokatory STL wydają się nie pasować do preferowanych strategii alokacji przy tworzeniu gier. Oczywiście można zastosować niestandardowe alokatory, ale to sprawia, że ​​cały pomysł jest mniej atrakcyjny, jeśli zastanawiasz się, czy dodać STL do bazy kodu innej niż STL.

Dodaj do tego, że jeśli twoja baza kodu jest inna niż STL, możesz nie mieć nikogo, kto zna wystarczająco STL lub koncepcje szablonów, aby poprawnie zaimplementować niestandardowe alokatory.


2

Myślę, że dyskusję tę można streścić w następujący sposób:

przeciętnie napisany kod specyficzny dla aplikacji <dobrze napisany kod ogólnego przeznaczenia <dobrze napisany kod specyficzny dla aplikacji

Każdy, kto ma własne rozwiązanie należące do kategorii 3, z pewnością zna odpowiedź na pierwotne pytanie dotyczące konkretnego problemu. STL wpada do kategorii 2. Więc dla kogoś, kto potrzebuje, aby zadać pytanie, „powinny I użyć STL”, odpowiedź brzmi: prawdopodobnie tak.


2

STL jest w porządku do użytku na PC, ponieważ jego zaawansowany system pamięci wirtualnej sprawia, że ​​potrzeba starannego przydzielania pamięci jest nieco mniej istotna (chociaż trzeba być bardzo ostrożnym). Na konsoli, z ograniczoną pamięcią wirtualną lub bez niej oraz z nadmiernymi kosztami braku pamięci podręcznej, prawdopodobnie lepiej nie pisać niestandardowych struktur danych, które mają przewidywalne i / lub ograniczone wzorce alokacji pamięci. (I na pewno nie pomylisz się, robiąc to samo w projekcie gry na PC).


1

Myślę, że to pytanie jest naprawdę większym pytaniem bez pytania - czy powinienem używać X w moim Y ? Jedynym sposobem, aby naprawdę odpowiedzieć, jest wypróbowanie go samemu. Dla każdej osoby, która twierdzi, że X działa świetnie, znajdziesz kogoś, kto mówi, że to okropne. I oba mają rację - do swojego projektu.

Wspaniałą rzeczą w oprogramowaniu, w przeciwieństwie do większości innych dyscyplin, jest to, że zawsze możesz później zmienić rzeczy, jeśli okaże się, że nie działa tak, jak byś tego chciał. Dowiesz się później, że STL nie działa dla Ciebie w tym projekcie? Rozerwij to, umieść coś innego na swoim miejscu. Nie podoba ci się, jak podzieliłeś obowiązki między swoje przedmioty? Refaktor. Nie podoba ci się, że używałeś obiektów? Zastąp je prostymi metodami C. Nie podoba ci się, że wszystko jest przechowywane w strukturach i metodach manipulowania nimi? Zamień je na obiekty C ++.


1
Podczas gdy masz rację, za refaktoryzację może być ogromna kara; więc podjęcie świadomej decyzji z góry zamiast arbitralnej pozwoli zaoszczędzić czas na dłuższą metę.
Alan

1

Mówię nie do STL. Mój powód jest dość prosty:

  1. Nie potrzebujesz STL do pisania gier. Nawet duże.
  2. STL znacznie wydłuża czas kompilacji.
  3. Duży czas kompilacji prowadzi do mniejszej liczby iteracji w trakcie rozwoju.

Uważam, że liczenie iteracji ma najwyższe znaczenie, więc po prostu trzymam się z dala od STL i wszelkich innych technik programistycznych, które spowalniają iteracje (jak na przykład architektura lub języki skryptowe, które należy skompilować).

Kosztowne iteracje prowadzą do ogromnych zespołów programistów, którzy próbują załatwić sprawy przy bardzo niewielkiej liczbie rzeczy. Widziałem to i słyszałem, a jednym z winowajców wydaje się być czas kompilacji bibliotek szablonów.


1
Zgadzam się co do czasów kompilacji. Każdy znaczący czas kompilacji podwaja ilość utraconej pracy; np. jeśli kompilacja trwa 5 minut, za każdym razem spędzisz 10 minut na kawie. ;)
Ipsquiggle

Chociaż widzę obie strony tego argumentu, muszę powiedzieć, że zdecydowanie się z tym zgadzam, Richard. +1.
Inżynier
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.