FAQ:
cocos2d de I-Phone: A que velocidade é cocos2d (em comparação com outros motores de jogo)? How fast is cocos2d (compared to other game engines)?Procure o meu cocos2d documentos de perguntas feitas por usuários de I-Phone & Seminários
Por favor observe que a pesquisa de blog na esquina certa superior não procura os meus documentos de perguntas feitas por usuários e Seminários.- Observe: por favor não compartilhe conexões de carregamento diretas a arquivos PDF, as conexões de carregamento vencem depois de uns minutos de par!
A pergunta é demasiado geral para ser respondida. Entendo a noção - se você estiver indo comprar um carro você quer saber a que velocidade pode ir. Mas como com carros, se você só for de carro em volta na cidade o topspeed simplesmente não lhe importa. But as with cars, if you only drive around in the city the topspeed simply doesn't matter to you.
A maior parte de programadores de jogo começam somente estão indo de carro em volta da cidade do futuro previdente. Se o código eles estão continuando a trabalhar for lento, não é quase nunca a falta de motor de jogo. Vi muito código de jogo de principiante ou semiprofissional. Em quase todos os casos houve só duas questões que causaram questões de realização severas: o revelador foi qualquer sobreambicioso (normalmente ligado com não entender as limitações da plataforma e gargalos) ou o código simplesmente não foi escrito com a velocidade em mente (normalmente ligado com uma falta de entender o motor de jogo, linguagem de programação e plataforma). I've seen a lot of beginner's or semi-professional's game code. In almost all cases there were only two issues that caused severe performance issues: the developer was either over-ambitious (usually coupled with not understanding the platform's limitations and bottlenecks) or the code was simply not written with speed in mind (usually coupled with a lack of understanding the game engine, programming language and platform).
Para quase todos os reveladores não importa a que velocidade cocos2d é em comparação com algum outro motor. A verdadeira pergunta deve ser: o que ele pode fazer para você? Quanto tempo ele o salvará construindo o seu jogo? Ele tem editores de jogo? É fácil construir elementos de Interface de Usuário como botões? Ele fá-lo franco e fácil colaborar com outros? E assim por diante... estes são as perguntas que você tem de perguntar antes de tudo avaliando um motor de jogo. what can it do for you? How much time will it save you building your game? Does it have game editors? Is it easy to build User Interface elements like buttons? Does it make it straightforward and easy to collaborate with others? And so on ... these are the questions you need to ask first and foremost when evaluating a game engine.
Em todo o caso é um processo de aprendizagem de todos nós. Se você se incomodar com a realização, comece simples. Estou seguro que você encontrará cocos2d bastante rápido em primeiro lugar, e os programadores experimentados podem fazer maravilhosas coisas com ele e não são limitados em absoluto. Penso que isto diz tudo ele. I'm sure you'll find cocos2d fast enough to begin with, and experienced programmers can make wonderful things with it and aren't limited at all. I think that says it all.
Se você realmente quiser saber o que cocos2d pode realizar em circunstâncias muito específicas então dão uma olhada durante os Testes de Realização cocos2d.
Exemplos de metas sobreambiciosas
- o desenho 100 + grandes Duendes com contextos parallaxing multiem camadas mais efeitos de partícula e objetos de física e espera de 60 fps
- a utilização de demasiados objetos de jogo que faz que a laços simples computem milhões de itens cada armação
- emulação shader efeitos em software manipulando memória de textura cada armação
O PSP-3000 nesta imagem é somente uma lembrança que você não pode esperar o mesmo nível de qualidade visual e complexidade no I-Phone do que no PSP. Não ainda de qualquer maneira. O I-Phone 3GS pode vir perto e o iPad pode ser de fato superior - mas a maioria dos seus clientes ainda está dirigindo o I-Phone 1os e 2os dispositivos de geração! Tente guardar as suas expectativas em um Nintendo nível de DS, e logo quando você adquire aquela execução bem, você sempre pode pensar na soma de mais heróis positivos visuais mais tarde. The iPhone 3GS may come close and the iPad may actually be superior - but the majority of your customers is still running iPhone 1st and 2nd generation devices! Try to keep your expectations on a Nintendo DS level, and then when you get that performing well, you can always think about adding more visual goodies later on.
Exemplos de código não escrito com velocidade em mente
- cada objeto de jogo verifica cada outro objeto de jogo se for mais fechado do que x para se. Com 1000 objetos isto causa 1.000 * 1.000 = um milhão de cheques executado. A melhor solução é atravessar a lista dos 1000 objetos e realização do cheque no resto 999 objetos, o seguinte laço só verifica o resto 998 objetos, e assim por diante. Isto trabalha porque se A não estiver perto de B, então B não pode estar perto de A, portanto podemos omitir aqueles. Ver o exemplo de pseudocódigo na imagem em cima. The better solution is to go through the list of all 1000 objects and doing the check on the remaining 999 objects, the next loop only checks the remaining 998 objects, and so on. This works because if A isn't close to B, then B can't be close to A, so we can skip those. See the pseudocode example in the image above.
- o desenho do grande número de objetos do lado de fora da tela sem algum cheque simples para desenhar só objetos que não são pelo menos parcialmente na tela
- movimento de muitos objetos distâncias só pequenas usando cocos2d Ações - isto causa muitos ciclos alloc/dealloc e pode afrouxar a realização. Para melhorar este código movem os objetos manualmente acrescentando manualmente uma velocidade cada armação às posições do objeto. Um modo bastante eficaz de fazer isto deve usar um motor de física para ter o movimento de objetos com velocidades fixas em uma direção dada. One rather effective way to do this is to use a physics engine to have objects move at fixed speeds in a given direction.









Esclarecimento de correio. Agradecimentos!
E, naturalmente, tenho alguns pergunta
- tudo é relativo, mas para o código comum é melhor para usar NSString, NSArray (e pagar o preço de criar novos objetos) ou os mutáveis? Que podem ser os parâmetros para selecionar entre cada um?
- Estou admirando-me se o novo I-Phone 4.0′s maior realização será uma questão. Os jogos que dirigem lisamente no I-Phone 1os e 2os dispositivos de geração correrão provavelmente demasiado rápido?
Oi Max,
duvido que os NSMutable* datasets sejam assassinos de realização. Não fiz nenhum teste mas estou bastante seguro que se você não os modificar em absoluto eles executarão provavelmente tão bom como os não-mutáveis. Agora, uma vez você *do* tem de modificar as tabelas ou cadeias está bem tê-los mutável para que o material seja cuidado para você nos bastidores. De outro lado, se você sabe que você só estará criando os itens uma vez mas nunca re-encomendar, retirar ou acrescentar que os outros então usam os não-mutáveis. Para mim é uma matéria de caso de uso em vez de realização. Now, once you *do* need to change the arrays or strings it’s good to have them mutable so that stuff is taken care for you behind the scenes. On the other hand, if you know that you’ll only be creating the items once but never re-order, remove or add others then use the non-mutable ones. For me it’s a matter of use case rather than performance.
Os jogos não correrão mais rápido em mais novos dispositivos. o cocos2d's CCDirector assegura-se disto. Você melhora framerates naturalmente mas não mais rápido gameplay. Isto mantém-se ser verdade para todos os motores de jogo modernos. You do get better framerates of course but not faster gameplay. That holds true for all modern game engines.