FAQ:
cocos2d para I-Phone: Aviso de derechos de autor & Permisos Copyright Notice & PermissionsBusque mi cocos2d preguntas frecuentes de I-Phone & Seminarios
Por favor note que la búsqueda de blog en la esquina correcta superior no busca mis preguntas frecuentes y Seminarios.- Note: ¡por favor no comparta relaciones de descarga directas a archivos PDF, las relaciones de descarga expiran después de unos minutos de pareja!
Este documento es Copyright 2010 (C) por Steffen Itterheim. Todos los derechos reservados.
Este documento fue creado exclusivamente para www.learn-cocos2d.com.
Usted no puede cargar y recibir este documento de un sitio web público, foro, o cualquier otra clase del depósito de archivo en público accesible. En cambio conecte con mi Base de Conocimiento o la Subpágina deseada en: http://www.learn-cocos2d.com/knowledge-base http://www.learn-cocos2d.com/knowledge-base
Usted no puede reimprimir los contenido de este documento en entero o partes para revistas de letra, periódicos, etc. sin mi permiso escrito previo.
Usted es animado a compartir este documento entre sus pares dados que el acceso al documento permanece gratuito (excluyendo los honorarios del usuario del acceso a internet). Le permiten cotizar extractos de este documento de su propio sitio web o en comentarios según la doctrina de Uso justo.
Ilustración de correo. Gracias!
Y, por supuesto, tengo unos cuantos pregunta
- ¿todo es relativo, pero para el código común es mejor para usar NSString, NSArray (y pagar el coste de crear nuevos objetos) o los mudables? ¿Cuál puede ser los parámetros para elegir entre cada uno?
- Me pregunto si el nuevo I-Phone 4.0′s mayor rendimiento será una cuestión. ¿Los juegos que dirigen suavemente en el I-Phone 1ros y 2dos dispositivos de generación correrán probablemente demasiado rápido?
Hola Max,
dudo que los NSMutable* datasets sean asesinos de rendimiento. No he hecho ninguna prueba pero estoy bastante seguro que si usted no los cambia en absoluto ellos funcionarán probablemente tan bueno como los no mudables. Ahora, una vez usted *do* tiene que cambiar las series o cuerdas está bien tenerlos mudable de modo que la materia sea tenida cuidado para usted entre bastidores. Por otra parte, si usted sabe que sólo creará los artículos una vez, pero nunca pedir de nuevo, quitar o añadir que los otros entonces usan los no mudables. Para mí es un asunto de caso de uso, más bien que rendimiento. 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.
Los juegos no correrán más rápido en dispositivos más nuevos. el cocos2d's CCDirector se asegura de esto. Usted mejora framerates por supuesto, pero no más rápido gameplay. Esto se mantiene para todos los motores animosos modernos. You do get better framerates of course but not faster gameplay. That holds true for all modern game engines.
Hola gaminghorror. Gracias por toda la gran información sobre su blog
que Realmente encuentra esto útil.
Quise preguntar sobre su código de fondo de paralaje encima – uso esto en un proyecto de prueba, pero no puede parecer consigo que el embaldosado quepa perfectamente al lado de eachother. En otras palabras, mi elfo que tejo (que es 480, 320 en la talla) teja, pero cuando el nuevo elfo comienza, hay un hueco negro aproximadamente 25 pixeles amplios entre el nuevo y el viejo. ¿Es allí algún camino a elliminate este hueco? He tratado de buscar los foros cocos2d etc., y he encontrado la información sobre la 2da proyección que apaga etc. … pero nada de eso me ha ayudado hasta ahora … A intentar e ilustrar lo que consigo, esto es lo que consigo el desplazamiento a través de la pantalla de dispositivo (el x's son el espacio en blanco de elfo es el hueco negro que consigo): Is there any way to elliminate this gap? I have tried searching the cocos2d forums etc, and found info on 2D projection turning off etc… but none of that has helped me so far… To try and illustrate what I am getting, this is what I get scrolling across the device screen (x’s are the sprite white space is the black gap I get):
xxxxxxxxxxxxxxx | |xxxxxxxxxxxxxxxx | |xxxxxxxxxxxxxxxxxx | |xxxxxxx
¿Parece que esto es una compensación de colocación, está seguro usted que los elfos son exactamente 480 pixeles aparte cada uno? Ambos también tienen que tener mismo anchorPoint. Y si usted cambia la escala de los elfos, la compensación también tiene que ser ajustada apropiadamente. And if you change the scale of the sprites, the offset also needs to be adjusted appropriately.
Usted podría querer probar la colocación con elfos más pequeños de modo que al menos dos de ellos quepan completamente en la pantalla.
Hola GamingHorror, muchas gracias por la respuesta
Tan esta mañana yo me desperté y tenía una mente clara – pensaba en ello un rato Mi elfo para el fondo es exactamente 480×320 – es decir screensize. El hueco yo veía la clase de 20-30 pixeles mirados alrededor entre cada elfo repetido. ¿Entonces yo pensaba, oye, en 480, están dándome sólo una textura que es 512 en el derecho de talla? Tan tal vez el que hace un lleno 512pixel textura. Entonces volví para fotohacer compras, y aumenté mi anchura de elfo a 512 (como mí wouldnt pierden cualquier rendimiento de todos modos) y dio a esto un intento, usando su código: So I thought, hey, at 480, I am just being given a texture that is 512 in size right? So maybe its doing a full 512pixel texture. So I went back to photoshop, and increased my sprite width to 512 (as I wouldnt lose any performance anyway) and gave this a try, using your code:
CCSprite *background = [CCSprite spriteWithFile: "tile1.png"
rect:CGRectMake (0,0, 480*50, 320)];
[mí addChild:background];
[fondo setPosition:ccp (winSize.width/2, winSize.height/2)];
ccTexParams params = {GL_LINEAR, GL_LINEAR, GL_REPEAT, GL_REPEAT};
[background.texture setTexParameters: ¶ms];
¡y esto lo clasificó! No más huecos. ¡Muchas gracias por las agujas también – yo no había pensado en anchorPoints! Muchas gracias por el gran blog. ¡Soy suscrito! Thanks so much for the pointers too – I hadn’t thought about anchorPoints! Thanks again for the great blog. I am subscribed!
Ah sí, si usted usa GL_REPEAT entonces la talla de imagen debe ser un poder de dos. Eg 64×64 o 512×128
Imponente – que aclara cosas para mí y tiene el sentido perfecto ahora. Gracias por confirmación. ¡Mi desplazamiento de paralaje acodado parece dulce ahora! My layered parallax scrolling is looking sweet now!
¿Tan otra pregunta rápida … adivino que no será posible usar un spritesheet con GL_REPEAT? Sobre todo el camino usted tiene que crear un CGRect …
Actualmente hago otra gráfica de spritesheets como esto:
CCSprite *projectile = [CCSprite spriteWithSpriteFrameName: "missile.png"];
Que son cargados de mi.plist / spritesheet. ¿No posible adjudicar el fondo GL_REPEAT como esto?
Ya que GL_REPEAT es un parámetro de textura, se aplica a la textura entera, entonces usted tendrá que usar una textura de imagen sola, y la talla debe ser un poder de 2, eg 128×16 o 256×256.
Esto también excluye el uso de spritesheet.
Usando esta técnica esto trabaja bien en el simulador, pero en el dispositivo la textura es super-blocky y pixellated. Dirijo esta prueba sobre cocos2d 0.99.5.
Ive intentó tanto con 256×256 como con 512×512 texturas, y el resultado es el mismo. El simulador repite perfectamente, extensiones de dispositivo y pixellates la textura horriblemente.
¿Tiene usted cualquier idea por qué esto pasa?
Hmmm, no realmente. ¿Adivino que podría estar relacionado con la demostración de Retina, prueba usted en un dispositivo de retina?