STL para jogos, sim ou não? [fechadas]

144

Toda linguagem de programação possui sua biblioteca padrão de contêineres, algoritmos e outras coisas úteis. Com linguagens como C #, Java e Python, é praticamente inconcebível usar a linguagem sem a sua lib padrão.

No entanto, em muitos jogos C ++ em que trabalhei, nós não usamos o STL, usamos uma pequena fração dele ou usamos nossa própria implementação. É difícil dizer se essa foi uma decisão acertada para nossos jogos, ou simplesmente tomada por ignorância do STL.

Então ... o STL é um bom ajuste ou não?

maravilhoso
fonte
14
O EASTL é uma boa leitura open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html
Matias Valdenegro
11
Sim, esse foi o que eu quis dizer com "usamos nossa própria implementação". :)
munificent
3
Se você tiver a oportunidade de localizar e comprar as melhores jóias de programação de jogos, faça-o. Existe um título de artigo "Usando o STL na programação de jogos", de James Boer, ArenaNet, onde ele faz um bom caso ao usar o STL.
Chiguire
Na verdade usando Java sem a sua lib padrão é bastante concebível, é chamado de J2ME: p
Bart van Heukelom
11
Ótima pergunta!
Alan

Respostas:

191

Quando eu trabalhei no desenvolvimento profissional de jogos, o STL era muito imaturo e inchado. Mas isso foi há> 10 anos atrás.

Agora, trabalho em simulação militar, que tem requisitos de desempenho ainda mais difíceis (como a taxa de quadros nunca pode ficar abaixo de alguns FPS). Na simulação militar, o STL é usado em todo o lugar.

Algumas pessoas que dizem para você não usar STL usam o argumento de que nem sempre é a solução perfeita ou mesmo a melhor para o problema. Mas isso não é uma resposta para a pergunta. A pergunta deve ser: existe algo inerentemente errado no uso do STL nos jogos? Eu diria que não, o STL é, na maioria das vezes, uma implementação melhor do que o que um usuário criaria por conta própria.

Apenas certifique-se de saber como usar o STL e usá-lo em seu jogo. Leia alguns livros e veja o código de implementação no STL que você está usando.

kevin42
fonte
49
Este é um conselho bastante sólido. O meme "STL é lento" não é verdade há pelo menos cinco anos e provavelmente bem mais. Ele continuará vivo, como as bobagens "Java é lento" e ".NET é lento", até que se torne evidente para todos que não é mais o caso. O STL ajuda a escrever melhores programas; Eu diria que não usá-lo, na maioria dos casos (além de 0,1% em algum lugar), é irresponsável. (. As alegações de que ele não se encaixa um determinado domínio do problema são muitas vezes mais de uma acusação da forma como o problema foi abordado, e não a própria STL Fix seu código, pessoal.)
Ed Ropple
5
@ Ed Ropple: Eu acho que o problema não é que STL não se encaixa em um determinado problema, o problema é que ele se encaixa em muitos problemas, o que torna o código muito complexo. É assustador como as pessoas usam o STL em excesso e acho que essa é uma das causas pelas quais tantos (inclusive eu) se abstêm de usá-lo. Como um exemplo que eu vi há muito tempo atrás, onde a pergunta era como obter o máximo de três números, uma das respostas os empurrava para um vetor std :: e depois std: classificá-lo. Isso está forçando definitivamente uma solução desnecessária a um problema muito simples.
Simon
22
@ Simon: com todo o respeito, o último exemplo é um sinal de extrema falta de noção, e não tem nada a ver com STL ... essa pessoa faria o mesmo em qualquer outro idioma com listas que podem ser classificadas. É o pensamento dele que está quebrado.
ggambett
O @EdRopple tenta implementar um analisador STL para arquivos de imagem PPM (menos de 100 linhas de código no total, se direcionar apenas para P6 ou P3). Metade do código resultante é apenas para ignorar as linhas de comentário, porque o STL não fornece algo comoif(stream.nextCharacter() == '#') stream.skipLine();
GameDeveloper 14/11/2015
@ DarioOO Eu não conheço esse formato de arquivo, mas é para isso que servem os adaptadores e filtros de fluxo. Escrevi esse comentário há cinco anos, lembre-se (e, ocasionalmente, continua voltando!), Mas hoje em dia escrevo sobre qualquer coisa que não seja super, super-crítica em um estilo funcional baseado em transformação e questões como a que você está descrevendo cair fora do problema. Eu realmente não me importo tanto assim com contagem de linha (e IMO nem deve), eu me preocupo com justeza da aplicação, em seguida, clareza, o desempenho, e , em seguida, as coisas tais como comprimento de código.
Ed Ropple
63

Eu diria que, acima de tudo, é uma idéia melhor usar o STL, a menos que você saiba exatamente por que não deseja usá-lo.

Aqui está a coisa sobre o STL: ele é desenvolvido por pessoas mais inteligentes do que você. Isso não pretende ser ofensivo nem nada, é apenas que o STL é desenvolvido por pessoas cujo trabalho está realmente construindo o STL. Será praticamente tão rápido quanto a plataforma pode permitir e geralmente será muito mais robusto do que uma solução caseira (e isso deve ser uma preocupação, se não mais, do que se preocupar com a velocidade bruta - porque seu jogo precisa robustez um pouco mais do que você precisa de velocidade; o último não faz sentido sem o primeiro).

As queixas de que o STL impõe uma "visão estreita do mundo" me parecem um pouco tolas. Eles são recipientes. Eles têm um conjunto limitado de operações porque os contêineres têm conjuntos limitados de operações. O que você está fazendo que não combina com isso?

Ed Ropple
fonte
4
Não acho que alguém deva justificar por que não deve usar STL. Também não concorde com o argumento "use-o porque é mais esperto que você". STL foi concebido em torno de uma visão específica de um domínio do problema, e não apenas recipientes ou seja, algoritmos, alocadores, iteradores, traços etc. Isso é bastante justo, mas não é a única maneira de olhar para esse domínio problema
zebrabox
2
Então, você prefere código produzido em casa do que código geralmente testado e fortemente robusto? O domínio do problema não é tão diferente de projeto para projeto (além de talvez projetos incorporados - até os consoles têm implementações decentes de STL hoje em dia!). Independentemente do jogo, seu problema não é tão diferente assim, e se você estiver criando algo que pretende enviar, terá uma responsabilidade implícita de escrever código robusto. Reimplementar a roda levará a melhor robustez e flexibilidade? Eu me inclino para o "não". O fato de não ser o "único caminho" não implica que não seja geralmente superior.
Ed Ropple
20
Eu diria que gamedev é sobre fazer jogos , mas tudo bem. Se suas suposições são tão precárias que você está se aprofundando nesse tipo de alocação de recursos, sim, é necessário dar um passo atrás e reavaliá-las. Mas você pode criar aplicativos incrivelmente rápidos que também usam o STL - e, certamente, qualquer outra implementação - quando você realmente sabe o que está fazendo . Aprendendo o que você está fazendo> recusando o STL. Ninguém disse que o STL é sempre a melhor resposta. O que estou dizendo é que, se você não consegue explicar por que não é o melhor curso , deve usar o STL.
Ed Ropple
11
Eu não acho que seja provocativo - é redigido de maneira a deixar a memória de alguém, mas é uma postura extremamente conservadora e direta. Em resumo: as pessoas que desenvolvem o STL têm mais conhecimento e estão melhor equipadas do que alguém que acha que precisa fazer essa pergunta. Se você precisar perguntar a outra pessoa se o STL é apropriado ou não, quase certamente não terá o conhecimento específico do domínio para preparar adequadamente uma solução caseira.
Ed Ropple
4
"Será praticamente tão rápido quanto a plataforma permitir". Essa é uma mentira definitiva, já que muitos fornecedores de compiladores não podem se preocupar em reescrever a STL, de modo que ela realmente reduza o desempenho da arquitetura específica. A STL não tem garantia alguma sobre as características de desempenho, exceto o grande O. O, no entanto, pode ser tão eficiente ou ineficiente quanto o fabricante do compilador deseja.
Kaj
35

Vi poucas razões para não usar o STL para jogos.

Para os problemas de alocação de memória, muitas pessoas não sabem disso, mas você pode escrever alocadores personalizados para suas classes de contêiner STL. Alocadores são basicamente classes de política que você passa para seus modelos para determinar como as alocações são executadas. Usando esses recursos, você geralmente pode solucionar os problemas de memória que são problemáticos na sua plataforma de escolha.

Obviamente, se você estiver usando o STL e fazendo coisas idiotas, como mapas de cadeias de caracteres para tipos grandes e sem ponteiros, terá problemas maiores em sua mão.

Tetrad
fonte
na verdade, usar tipos grandes de não ponteiros no mapa é um bom caso de uso, porque os mapas stdlib têm o requisito de não invalidar os iteradores, o que força a implementação a usar ponteiros e elementos mapeados alocados individualmente. A melhor solução para jogos é usar google::sparse_mapou escrever os seus.
precisa saber é o seguinte
por que não um mapa denso?
GameDeveloper 14/11/2015
23

O STL padrão tem um número razoável de problemas que dificultam o uso com jogos, especialmente quando se trata de alinhamento de memória.

Uma variante personalizada, como o EA STL, foi especialmente projetada para jogos e pode proporcionar um desempenho de memória e usabilidade do console muito melhores. Tornou-se open source em 2016, sob uma cláusula BSD-3, com um repositório no GitHub .

Ben Zeigler
fonte
19
Problemas com o uso de memória e jogos do STL geralmente podem ser resolvidos com classes de alocador personalizadas. De fato, no meu trabalho anterior, nossa classe de vetor "personalizada" era apenas um invólucro fino std::vectorque substituía o alocador padrão.
Blair Holloway
11
@Blair Holloway: "Os alocadores personalizados são baseados em classe, não em instância. Alocadores são obrigados a construir e destruir objetos, além de alocá-los. Isso força a mistura de dois conceitos separados: alocação e construção. Esses são apenas alguns dos os problemas com stl-alocadores, infelizmente. " O EA STL apresenta vários outros motivos válidos pelos quais os alocadores de STD são ruins. Não é apenas "se podem ou não ser substituídos".
Simon
@ Simon - Não vou argumentar que o sistema de alocadores do STL é perfeito, porque não é. Demoramos muito tempo para encontrar uma solução que funcionasse. O que estou dizendo é que, em alguns casos, é possível obter uma solução viável para jogos usando STL e um pouco de trabalho com alocadores personalizados.
Blair Holloway
@ Simon - Para elaborar: embora o STL possa ser complicado, é um código muito bem testado e sem erros; se você puder usá-lo, economizará horas de trabalho tendo que depurar uma solução personalizada. Meu trabalho atual evita o STL em favor de alocadores caseiros, e tive que gastar tempo depurando e refatorando parte desse código, porque ele não está no mesmo nível de maturidade que o STL.
Blair Holloway
11
@ Simon: Estou um pouco atrasado para a festa aqui, mas estou curioso para dar um exemplo específico do que você quer dizer com isso. Qual é um bom exemplo de solução de um problema específico de uma maneira que o STL é geral demais para resolver com eficiência?
BRaffle
21

Aqui está o que Mike Acton (diretor de motores da Insomniac Games de Spyro the Dragon, Ratchet & Clank e Resistance) teve a dizer sobre isso quando solicitado aqui . Observe que ele foi questionado sobre o STL e o Boost em geral, relacionados ao uso no desenvolvimento de jogos.

STL / Boost, ele pertence ao gamedev? Se apenas partes dela, quais?

Você está perguntando sobre duas coisas diferentes aqui, certo? STL e Boost, separadamente. Mas, na verdade, minha resposta é a mesma: não há nada errado com nenhum deles, mas desencorajo o uso deles. O uso de qualquer um incentiva as pessoas a adaptar uma solução para um problema, em vez de encontrar uma solução para um problema. A solução deve sempre ser apropriada para os dados disponíveis e as restrições do hardware, etc. Tanto o STL quanto o Boost têm uma visão extremamente estreita do "mundo" e seu uso apropriado é limitado. Realmente, desencorajo-os porque eles levam os programadores a seguir na direção errada imediatamente; muitas vezes digo que, se você sentir que precisa de um deles, provavelmente não entenderá realmente o problema que está enfrentando. '

Também notei que a maioria dos desenvolvedores de jogos profissionais se esforça mais em C do que em C ++.

Quadro-chave
fonte
18
Não concordo com o esforço maior em relação ao C. A grande maioria dos desenvolvedores de jogos e escritores de SDK usa C ++. Na verdade, a última grande usuário C foi id e até mesmo Carmack tem passado para C ++ agora ...
Goz
82
O comentário do Sr. Acton parece superficial. De um modo geral, o STL é um bom ajuste para esses problemas. Se você está tentando fazer algo de modo que a abordagem STL pareça "errada", provavelmente é uma boa idéia reavaliar sua abordagem e ver se você está realmente fazendo isso de maneira inteligente. Na minha experiência, na maioria das vezes, você provavelmente não é. (É muito mais inteligente, IMO, para resolver um problema com o entendimento ela fortemente no contexto de suas ferramentas de jogar fora suas ferramentas apenas para refazer tudo do zero.)
Ed Ropple
50
Minha experiência com a STL tem sido quase oposta. É eficiente e economiza tempo. Se você sentir a necessidade de rolar sua própria biblioteca de modelos ou biblioteca de contêiner, tudo bem. Mas não finja que o STL (ou impulso, nesse sentido) é ruim. Eu usei o STL extensivamente em jogos comerciais para iPhone, Nintendo DS, Wii, PC, Mac e Xbox. Toda vez que fui forçado a usar a biblioteca "melhor" de outra pessoa, eu a encontrava ausente e com erros.
BR109
5
Funciona tão bem no DS quanto em qualquer outra plataforma em que o usei. Eu usei STL em todo o código da interface do usuário e AI. O jogo era ds.ign.com/articles/832/832147p1.html . Eu estava trabalhando em um pequeno estúdio que fazia parte da Amaze, que fazia parte da Fundação 9.
BRaffle
7
Mike tem tudo a ver com dados. Examinar os dados sugere o melhor método para transformar os dados. Aplique em larga escala e você terá programação. Nesse contexto, suas críticas fazem muito sentido. STL (e padrões de design) sugerem que, em vez de examinar os dados para encontrar uma solução, examinamos as soluções em nosso pacote de truques para encontrar uma que funcione com os dados. Não pretendo falar por Mike, mas acredito que ele sugeriria que essa maneira de abordar o problema é inversa e pode potencialmente levar a soluções ineficientes ou inchadas.
Dan Olson
19

Se você se reescrever algo que já existe no STL, por qualquer motivo, pare . Use o STL.

O STL foi otimizado ao longo de anos de análise e tempo, e é uma aposta segura que você provavelmente não escreverá algo mais eficiente. Isso não quer dizer que você deva usar STL onde uma solução mais simples possa ser possível (por exemplo, usar uma matriz quando você tiver uma quantidade conhecida de coisas, não uma lista stl ::), mas se estiver escrevendo sua própria implementação de um mapa ( a estrutura básica de dados, não o mapa do mundo dos jogos), você está fazendo errado.

Ricket
fonte
7
map <> quase nunca é o que você deseja usar para qualquer memória ou CPU eficiente no contexto de um jogo. hash_map <> quase sempre é uma escolha melhor, embora o desempenho do hash_map seja muito diferente do fornecedor. Se você está construindo um jogo que é para console ou possui recursos de rede escalável, o STL pode ser absolutamente muito lento ou inchado para seus propósitos.
21410 Ben Zeigler
3
O unordered_map <> agora está amplamente disponível e possui requisitos de desempenho extremamente rígidos no rascunho atual do TR1. (Para o ponto de especiais teriam eu acho - ele ainda proíbe hashing aberta, e enquanto isso é geralmente mais lento, eu não acho que deveria ser liminarmente proibida pela norma.)
5
O STL oferece algoritmos e contêineres. Nunca existe uma razão para não usar a versão stl de um algoritmo. Por exemplo, std::sortgeralmente usa introsort por baixo, incrivelmente rápido e complexo o suficiente para que você não queira fazer isso sozinho.
Deft_code 27/08/10
A verdade é que unordered_mapo C ++ 11 ou o boost são muito lentos, o que você deseja é um mapa de hash de endereço aberto, como google :: sparse_map ou o seu.
precisa saber é o seguinte
16

STL é um bom ajuste para jogos? Definitivamente. Os jogos são peças complexas de software, o STL fornece recursos que ajudam a gerenciar a complexidade, por isso é bom.

É uma boa opção para sua plataforma? Não necessariamente. Se você está escrevendo para um console, precisa ter muito cuidado com o uso de memória e cache. O STL não torna isso muito fácil.

Penso que, com demasiada frequência, confundimos "jogos" com "jogos em tempo real de alto desempenho que rodam em hardware incorporado ou sob medida", mas é importante fazer uma distinção. Se você está escrevendo um jogo do Windows que não está tentando rodar em tela cheia a 60fps constantes, não há razão para evitar as ferramentas fornecidas pela biblioteca padrão.

Kylotan
fonte
10

Sei que é muito tarde para a festa, mas as mudanças de tempo e as respostas ficam por aqui. O C ++ 11 tem mudanças bastante abrangentes, muitas das quais devem aumentar o desempenho do C ++ e da biblioteca padrão. Parece que aqueles que não usam o STL ou o Boost também tendem a não acompanhar os novos padrões, deixando as soluções em casa sem grandes melhorias, é claro que nem sempre é esse o caso.

Eu usei o STL em todos os projetos, desde meados dos anos 90 até hoje, com exceção de um curto período na EA. Eu acho que o lado anti STL teve algumas razões marginalmente racionais para não usá-lo. Aqueles se foram em grande parte. Alocadores personalizados são uma solução, usar reserva é outra e não passar coisas por valor é uma terceira, mas essas são bem simples e qualquer programador deve saber disso. Mais importante, porém, é o uso de algoritmos. Os escritores do compilador sabem exatamente o que um for_each () faz e pode otimizar o código. Isso não pode ocorrer com um loop inicial. for_each () em um objeto const é ainda melhor. A Microsoft otimiza for_each de várias maneiras, incluindo serialização. Eles também têm a biblioteca AMP que possui parallel_for_each (). Se você tiver uma chance, converse com os engenheiros do compilador sobre isso. Os compiladores de console otimizarão o que é usado, por isso ' um pouco de um problema de galinha e ovo. A Microsoft está ficando muito pesada com o C ++ 11 e o próximo XBox não será diferente. Não tenho ideia do PS4, ainda não conseguimos.

Alocadores personalizados são uma maneira de lidar com o problema de memória, mas outra opção (geralmente ignorada) é usar new e delete com base em classe. Enormes aumentos de desempenho podem ser obtidos dessa maneira.

A noção de que Boost e STL têm uma visão restrita da solução de problemas é pura insanidade. Estou surpreso com quantas coisas no STL e no Boost são personalizáveis ​​por meio de características e políticas. Procure uma comparação independente de maiúsculas e minúsculas como um exemplo.

Em relação aos longos tempos do link e ao inchaço do código, o novo modelo externo deve ajudar com isso. Geralmente, acho que os longos tempos de compilação vêm do excesso de acoplamento e uso indevido do pch.

A razão mais convincente para usar o STL em casa é que existem milhões de pessoas que podem ajudá-lo com o STL. Como sempre, não otimize prematuramente e teste, teste, teste.

Tavison
fonte
idéias interessantes; o que você quer dizer com " usar classe baseada em novo e excluir "? Você quer dizer, acelerar um processo usando objetos já existentes na pilha?
johnbakers
9

Este é um tópico importante no desenvolvimento de jogos. Pessoalmente, não o recomendo, exceto, talvez, pelo EASTL, como mencionado acima. Eu tenho dois problemas principais com o STL (tecnicamente "The C ++ Standard Library", como STL não é mais o nome) nos jogos. 1) A alocação dinâmica de memória geralmente desperdiça muito tempo de execução nos jogos quando o STL é usado. 2) O uso do STL incentiva uma abordagem de matriz de estruturas à arquitetura de jogos, enquanto uma abordagem de estrutura de matrizes é muito mais amigável ao cache.

Terrance Cohen
fonte
Como mencionado em outro lugar, você pode fornecer alocadores personalizados para as classes de contêineres - eles podem usar freelists, se desejar (matrizes pré-alocadas). A matriz de estruturas versus a estrutura de matrizes depende muito do que você está tentando fazer - não há uma regra rígida sobre qual é a melhor.
Skizz
Aprecio seu argumento de que é importante entender bem o problema que você está resolvendo. Mas com respeito, ainda acho que discordo da sua conclusão. Todo problema tem padrões de uso que não podem ser expressos para alocadores STL personalizados, mas podem ser facilmente aproveitados em um contêiner personalizado, como um alocador de bloco fixo implementado com uma matriz plana. A aplicação de uma transformação fixa em uma matriz de tipos homogêneos provavelmente resultará em uma coerência de cache muito melhor do que na iteração sobre um vetor de tipos polimórficos e na invocação de métodos virtuais.
Terrance Cohen
5

Depende. Qual é o tamanho do projeto, quais plataformas e qual é o cronograma?

Se você estiver trabalhando em um projeto grande, em plataformas com recursos limitados, com um cronograma e orçamento significativos, poderá poupar muitos problemas evitando o inferno inevitável que estará olhando para meio milhão de linhas de código de linha que é repleto de STL, não pode manter uma taxa de quadros acima de 30, consome RAM suficiente para caber em mais ativos e leva 2 horas para construir.

Em outras situações, no entanto, o STL e até o Boost podem ser muito úteis quando aplicados adequadamente. Trabalhei em títulos que usavam uma seleção de STL / Boost e eram um sonho absoluto de codificar: menos bugs / vazamentos e código de fácil manutenção, mais tempo codificando novos recursos divertidos! Especialmente para projetos de hobby, é uma grande vitória no departamento de motivação.

Saiba quando negociar desempenho por conveniência!

Jason Kozak
fonte
11
"Saiba quando negociar desempenho por conveniência". Sim. Esta frase por si só é uma resposta tão boa quanto qualquer outra. Descubra o que você precisa alcançar com o seu jogo, consulte os colegas e decida se o STL o ajudará a chegar lá ou atrapalhá-lo. Eu diria que, se você não quer definir a barra para gráficos e desempenho de próxima geração com o seu jogo, a STL provavelmente o ajudará.
gkimsey
4

IMHO Eu diria que é um bom ajuste, já que o STL já funciona bem e é otimizado para as tarefas para as quais foi criado. Além disso, você está trabalhando em um jogo, portanto, use as ferramentas que você tem em mãos que tornam sua vida mais fácil e seu código menos propenso a erros.

Por que se preocupar em reinventar a roda quando você pode trabalhar em outra coisa como a IA do jogo, a experiência do usuário ou melhor ainda? teste e depuração?

pctroll
fonte
2
Na prática, no final de um projeto, o desempenho tende a ser um problema crítico. Se você usa o STL, tem muito pouca oportunidade de otimização, porque pega seus aplicativos específicos e os resolve de maneira geral. Resolver casos específicos de uma maneira específica (e sem alocação dinâmica de memória) quase sempre tem desempenho superior.
Terrance Cohen
2
Mas se você não deseja alocação dinâmica de memória, não deve usar o STL. Esse é o tipo de questão. Seu próprio código não será melhor e certamente pode ser bem pior. A decisão do projeto de usar indevidamente o STL é o problema aqui, não o STL, seus recursos ou suas características de desempenho. Você está atacando a parte errada do problema.
Ed Ropple
4

O STL é absolutamente bom para uso em jogos, desde que você o entenda bem. Nosso mecanismo faz uso extensivo dele e nunca foi um problema. Não tenho nenhuma experiência com desenvolvimento de console, que pode ser uma história totalmente diferente, mas é bem suportada em todas as plataformas de PC (Windows / Mac / Linux).

O mais importante é entender quais são os pontos fortes e fracos de cada tipo de contêiner e escolher o contêiner correto para o trabalho que você está fazendo.

Jason Morales
fonte
4

Meu ex-empregador deixou de usar um conjunto robusto de classes de contêineres personalizadas para a STL. Os tempos de construção aumentaram e a facilidade de depuração diminuiu, ambas de maneira bastante significativa. Se estivéssemos começando do zero, o STL (talvez melhor utilizado) provavelmente faria sentido, mas nunca ficou claro para mim que ganhámos algo ao mudar para o STL que justificasse a execução de códigos funcionais, rápidos e depuráveis.

Para meus projetos pessoais, se o STL se encaixa ou não, depende do projeto. Se estou tentando fazer algum trabalho otimizado, orientado a dados, com acesso a memória e cache, ao estilo de Mike Acton, pensarei pelo menos em rolar minhas próprias estruturas de dados personalizadas. Se eu estiver criando um protótipo de alguns algoritmos ou jogabilidade e não me importo com desempenho, escalabilidade, plataforma de destino, etc., pegarei automaticamente o STL.

Tom Hudson
fonte
4

Meus 2 centavos sobre isso é que o STL funciona muito bem. Estou desenvolvendo um mecanismo de jogo 3D (não de qualidade AAA, mas avançado o suficiente - tipos de entidade com script, renderizador diferido, física Bullet integrada) para PC e ainda não vi os contêineres se tornarem o principal gargalo. O uso incorreto da API 3D e algoritmos ruins foram os melhores alvos (determinados por criação de perfil!) Toda vez que entrei e tentei obter um pouco mais de desempenho.

Branan
fonte
3

Eu construí jogos usando STL e gosto, e parece ter um bom desempenho.

Kevin Laity
fonte
3

Boa pergunta! Uma pergunta mais específica é quais são alguns requisitos comuns que um jogo teria que não podem ser atendidos com STL e Boost.

Na minha experiência, as limitações limitadas de memória do hardware do console tornam qualquer tipo de contêiner de tamanho dinâmico uma má idéia, independentemente de quão inteligente seja seu alocador personalizado. Contêineres sem limites deliberados incentivam os programadores a escrever código que não restringe os limites de seus conjuntos de dados. Dependendo de inúmeras variáveis ​​difíceis de rastrear, você pode exceder as limitações de memória. Tenho um palpite de que essa é uma das principais causas de instabilidade nos jogos modernos.

Além disso, o uso excessivo de modelos pode levar a tempos de compilação muito longos em uma grande base de código e inchará o tamanho do seu executável, para que ele não caiba mais no cache de, digamos, um núcleo auxiliar em um ps3.

No entanto, para o desenvolvimento somente para PC, acho que o STL e o Boost são muito bons. Embora as soluções de casos gerais nem sempre sejam ideais, elas geralmente são boas o suficiente. Sua primeira solução para um problema quase nunca é ideal, e você aprimora ou substitui as inadequações até que sejam boas o suficiente.

Evan Rogers
fonte
2

O STL é adequado para o seu jogo se o STL for adequado para o seu jogo.

Como em todas as opções de tecnologia feitas durante o desenvolvimento, você precisa avaliar os prós e os contras - rolar minha própria biblioteca me proporcionará um uso, desempenho e produtividade de memória mais benéficos do que simplesmente usar o STL? Possivelmente; embora seja igualmente fácil criar uma vectorimplementação que use mais memória, seja mais lenta e exija grandes quantidades de manutenção para permanecer funcionando em comparação com o que já existe.

As pessoas não devem evitar usar o STL em seus jogos porque outras pessoas evitam usar o STL em jogos; eles devem evitar usá-lo se ponderarem todas as opções e realmente acreditarem que outra implementação melhorará a qualidade de seu produto.

Blair Holloway
fonte
2
Eu concordo 100% com a última parte do seu comentário, mas eu iria além: se você puder demonstrar conclusivamente por que o STL não é uma boa opção, não use o STL. Caso contrário, faça. O culto à carga (tudo, desde "oh, desenvolvedores de jogos usam C ++!" A "oh, desenvolvedores de jogos não usam o STL!") É prejudicial. Gostaria, no entanto, de abordar um pouco o seu segundo parágrafo: é muito improvável que as pessoas que ainda sejam ingênuas o suficiente para pensar em reimplementar o STL sejam uma boa idéia que construam um melhor vectorque o pessoal do STL. No momento em que você pode fazê-lo, você não acha mais necessário! :-)
Ed Ropple
2

Como na maioria das perguntas, a resposta nunca é "sim ou não", preto ou branco. STL é um bom ajuste para alguns problemas, usá-lo para esses problemas deve ser bom. É um erro supor que é inútil, mas também é um erro supor que é apropriado usá-lo em todas as situações.

O maior problema a ser observado ao usar STL no desenvolvimento de jogos é a alocação de memória. Os alocadores padrão da STL não parecem se encaixar bem nas estratégias de alocação preferidas para o desenvolvimento de jogos. É claro que os alocadores personalizados podem ser usados, mas isso torna a idéia menos atraente se você estiver pensando em adicionar STL a uma base de código não STL.

Adicione a isso que, se sua base de código não for STL, talvez você não tenha ninguém familiarizado o suficiente com STL ou conceitos de modelo para implementar corretamente os alocadores personalizados.

Dan Olson
fonte
2

Penso que esta discussão pode ser resumida da seguinte forma:

código específico da aplicação escrito mediocramente <código geral bem escrito <código específico da aplicação bem escrito

Qualquer pessoa cuja solução doméstica se enquadre na categoria 3 certamente sabe a resposta à pergunta original para o seu problema específico. O STL cai na categoria 2. Assim, para alguém que precisa de fazer a pergunta, "deveria eu usar o STL", a resposta é provavelmente sim.


fonte
2

O STL é adequado para uso em um PC, porque seu sistema avançado de memória virtual torna a necessidade de alocação cuidadosa de memória um pouco menos crucial (embora ainda seja preciso ter muito cuidado). Em um console, com recursos de memória virtual limitados ou inexistentes e custos exorbitantes de perda de cache, é provável que você escreva estruturas de dados personalizadas com padrões de alocação de memória previsíveis e / ou limitados. (E você certamente não vai dar muito errado ao fazer o mesmo em um projeto de jogo para PC.)

Mustafa Ekici
fonte
1

Eu acho que essa pergunta é realmente uma pergunta não feita maior - devo usar o X no meu Y ? E a única maneira de realmente responder a isso é tentar por si mesmo. Para cada pessoa que encontrar que diz que X funciona muito bem, encontrará alguém que diz que é horrível. E os dois estão certos - para o seu projeto.

O melhor do software, diferentemente da maioria das outras disciplinas, é que você sempre pode mudar as coisas mais tarde, se achar que não está funcionando da maneira que gostaria. Você descobre mais tarde que a STL não está trabalhando para você neste projeto? Rasgue, coloque outra coisa no lugar. Não gosta de como você dividiu os deveres entre seus objetos? Refatorar. Não gosta que você tenha usado objetos? Substitua-os por métodos C retos. Não gosta que tudo seja armazenado em estruturas e métodos para manipulá-los? Substitua-os por objetos C ++.

Dennis Munsie
fonte
11
Enquanto você estiver certo, pode haver uma penalidade enorme pela refatoração; portanto, tomar uma decisão informada antecipadamente, em vez de uma decisão arbitrária, economizará tempo a longo prazo.
Alan
1

Eu digo não ao STL. Minha razão é bastante simples:

  1. Você não precisa do STL para escrever jogos. Nem mesmo os grandes.
  2. O STL aumenta drasticamente o tempo de compilação.
  3. Um grande tempo de compilação leva a menos iterações no seu desenvolvimento.

Eu considero a contagem de iterações da mais alta importância, portanto, apenas me afasto da STL e de qualquer outra técnica de desenvolvimento que diminua as iterações (como a arquitetura por causa disso ou as linguagens de script que precisam ser compiladas).

Iterações caras levam a grandes equipes de desenvolvimento de pessoas tentando fazer as coisas com muito pouco de fato acontecendo. Eu já vi e ouvi, e um dos culpados parece ser o tempo de compilação das bibliotecas de modelos.

Richard Fabian
fonte
11
Eu concordo com os tempos de compilação. Qualquer tempo de compilação significativo dobra a quantidade de trabalho perdido; por exemplo, se a compilação durar 5 minutos, você gastará 10 minutos tomando café a cada vez. ;)
Ipsquiggle
Enquanto vejo os dois lados desse argumento, devo dizer que concordo plenamente com seu argumento, Richard. +1.
Engenheiro de