Apprenez & le développement de Jeu de Maître Cocos2D

J'ai sans doute que le compte de référence automatique (l'ARC) est le grand saut suivant en avant pour l'Objectif-C depuis l'introduction d'Objectif-C 2.0. L'ARC vous permet de mettre le fardeau de direction de mémoire sur (l'Apple LLVM 3.0) le compilateur et jamais penser retient, libère et autolibère jamais de nouveau.

Comme les premières expériences de beaucoup d'utilisateur avec l'ARC essaieront de convertir app existant, ils apprendront la façon dure que la conversion du code existant pour DÉCRIRE UN ARC n'est pas un feu & oubliez l'opération. Et comme c'est Internet, il y a aussi beaucoup d'hypothèses, fausses déclarations et d'autres mythes tournant autour de l'ARC se promenant.

Ainsi voici à peu près tout que vous avez besoin d'être au courant de l'ARC et d'un ARC-mythbusting aussi.

• Les Exigences de développement pour l'ARC apps
• Les Cibles de Déploiement minimales pour l'ARC apps
• Cibles de Déploiement exigées avec de faibles références zeroing
• Comment permettre l'ARC dans votre projet
• Compilez des erreurs après avoir échangé à LLVM 3.0
• Finir par des bibliothèques de tiers construire avec l'ARC
• La conversion d'app existant pour DÉCRIRE UN ARC
• “Ne peut pas Passer à l'ARC Objectif-C”
• Le fait de fixer la flèche tape dans C structs
• En Fixant C/C ++ la flèche change avec les acteurs construits un pont
• Fixer NSAutoreleasePool avec @autoreleasepool
• Les méthodes vous ne pouvez pas appeler (ou passer outre) plus
• Vous pouvez passer outre encore - (le vide) dealloc {}
• Restriction d'appellation de propriété
• Nouveaux mots clé de Propriété : fort et faible
• L'ARC défend le fait de synthétiser une propriété readonly sans qualificatif de propriété
• Pour les experts : le fait de découvrir à compile fois si l'ARC est permis
• Pour les experts : permettez l'utilisation de mots clé d'ARC avec les handicapés d'ARC
• Mythe : l'ARC n'a pas été prouvé fiable
• Mythe : l'ARC emporte le contrôle sur la direction de Mémoire
• Documentation de Référence d'ARC

Les Exigences de développement pour l'ARC apps

• Xcode 4.2
• Le compilateur d'Apple LLVM 3.0 (Construisent le Cadre)
• IOS app développement : le Léopard de Neige 10.6 et plus nouveau
• Mac app développement : le Lion 10.7 et plus nouveau

Il n'y a aucun développement d'ARC pour Mac apps sous le Léopard de Neige! Et Xcode 4.1 et ne vient pas plus tôt empaqueté avec le compilateur d'Apple LLVM 3.0 (le Bruit métallique) qui est la première version de compilateur de Bruit métallique à soutenir l'ARC.

Les Cibles de Déploiement minimales pour l'ARC apps

• appareils d'IOS : IOS 4.0 ou plus nouveau
• Ordinateur de Mac : Mac avec le processeur de 64 morceaux dirigeant le Léopard de Neige 10.6 ou plus nouveau.

Mac OS X apps avec l'ARC a permis sont toujours 64 morceaux apps. Vous ne pouvez pas construire l'ARC de 32 morceaux apps.

Macs avec au moins une 2 unité centrale de Duo de Base sera capable de diriger 64 morceaux apps. Macs avec le Duo de Base de 32 morceaux ou le Solo de Base (Yonah) les unités centrales ne peut pas diriger l'ARC apps. Les Macs de 32 morceaux ont été arrêtés près de la fin de 2006, à l'exception du Duo de Base Mac mini-qui a été arrêté en août de 2007. The 32-Bit Macs have been discontinued near the end of 2006, with the exception of the Core Duo Mac mini which was discontinued in August 2007.

Cibles de Déploiement exigées avec de faibles références zeroing

• appareils d'IOS : IOS 5.0 ou plus nouveau
• Ordinateur de Mac : le Lion 10.7 ou plus nouveau.

Vous ne pouvez pas utiliser "par hasard" de faibles références zeroing sans le remarquer. Vous devrez utiliser ou le mot clé @property faible ou le __ le faible mot clé en déclarant une variable. Si vous utilisez un de ces mots clé, le compilateur produira une erreur si vous n'avez pas encore fixé l'objectif de déploiement en conséquence à IOS 5.0 ou à Mac OS X 10.7. If you use one of these keywords, the compiler will generate an error if you haven’t yet set the deployment target accordingly to either iOS 5.0 or Mac OS X 10.7.

Tous Macs capable de Lion courant 10.7 peuvent diriger l'ARC de 64 morceaux apps. Le lion est premier 64-Bit-only Mac OS X système d'exploitation.

Comment permettre l'ARC dans votre projet

Vous serez besoin de vous assurer que le Cadre Construire pour le Compilateur pour C/C est montré ++/Objective-C au compilateur d'Apple LLVM 3.0.

C'est particulièrement important pour les projets existants qui peuvent encore être montrés pour utiliser LLVM GCC 4.2 ou un autre compilateur. Si vous ne choisissez pas le LLVM 3.0 compilateur, aucun de l'ARC ne s'est entendu les cadres se manifesteront dans la liste de Cadres Construire.

Avec LLVM 3.0 choisi comme le compilateur l'Objectif-C de Cadre Construire le Compte de Référence Automatique peut être montré à OUI. Si vous créez un nouveau projet d'un gabarit Xcode vous aurez aussi l'option de permettre l'ARC dans le nouveau sorcier de projet en choisissant l'Utilisation le Compte de Référence Automatique.

Compilez des erreurs après avoir échangé à LLVM 3.0

Si vous utilisiez auparavant un différent compilateur, il est absolument possible que LLVM 3.0 produise de nouveaux avertissements et des erreurs où il n'y avait personne auparavant, même avec les handicapés d'ARC. C'est le LLVM 3.0 compilateur qui est devenu un peu mieux lors du fait de découvrir le code potentiellement dangereux.

Je recommande d'abord construire votre app avec LLVM que 3.0 compilateur et ARC ont rendu infirmes, pour s'assurer tout LLVM 3.0 questions connexes ont été fixées avant d'essayer de convertir votre code pour DÉCRIRE UN ARC.

Par exemple, LLVM 3.0 est capable maintenant de découvrir une “gamme potentielle hors du terrain” les éditions grâce au projet de SAFECode et il un peu plus harcèle quand il vient à la fonte d'un type à un autre, en particulier rattaché aux ficelles de format. La plupart de ces éditions sont faciles à résoudre. En fait, LLVM 3.0 vous aide à déterminer où l'édition est par diagnostics expressif, mais malheureusement Xcode le cache pas mal à l'utilisateur. In fact, LLVM 3.0 helps you determine where the issue is through expressive diagnostics, but unfortunately Xcode hides that pretty well from the user.

Pour voir diagnostics expressif dans Xcode, allez chez le Navigateur de Rondin (Command+7) et choisissez-y le rondin le plus récent avec l'avertissement ou l'erreur :

Claquez alors le bouton de détails à droite du symbole d'avertissement/erreur (juste au-dessus "plus" le lien) pour voir le LLVM 3.0 déclaration diagnostics expressive, en montrant exactement au caractère ou à la gamme de caractères provoquant l'édition :

Finir par des bibliothèques de tiers construire avec l'ARC

La première chose à faire avec les bibliothèques de tiers incompatibles est de les construire comme une bibliothèque statique séparée. Prenez par exemple Cocos2D dont le gabarit de projet de Xcode met simplement tout le code de Cocos2D dans la cible de votre projet. Ce serait un cauchemar pour essayer et actualiser le code de bibliothèque Cocos2D entier pour soutenir l'ARC. Pendant que vous pouvez rendre l'ARC INFIRMES pour les dossiers de code source individuels avec le drapeau de compilateur-fno-objc-arc, il serait ennuyeux pour faire ainsi pour plus que juste quelques dossiers. It would be a nightmare to try and update the entire Cocos2D library code to support ARC. While you can disable ARC for individual source code files with the -fno-objc-arc compiler flag, it would be tedious to do so for more than just a few files.

Dès que vous construisez le code source Cocos2D séparément comme une bibliothèque statique, les changements exigés sont limités à trois endroits : CCDirector (enlèvent NSAutoreleasePool), CCActionManager (ajoutent __ unsafe_unretained) et CCArray (ajoutent __ unsafe_unretained, le refacteur inline le code dans le dossier de mise en oeuvre). Très petit Tim Games a exposé ces changements et fournit une fourchette de cocos2d-I-Phone qui est compatible avec l'ARC – si construit comme une bibliothèque statique.Tiny Tim Games have outlined these changes and provide a fork of cocos2d-iphone that is compatible with ARC – if built as a static library.

À propos, Kobold2D est complètement compatible avec l'ARC. En fait il a l'ARC permis par défaut dans tous les projets en retenant plein à l'envers la compatibilité si vous ne voulez pas utiliser l'ARC!

Si la construction d'une bibliothèque statique provoque encore trop d'éditions avec cette bibliothèque, allez ensuite au forum de cette bibliothèque, cherchez des postes rattachés d'ARC et/ou un soutien d'ARC de demande. Beaucoup de bibliothèques source ouvertes ne compilent même pas proprement avec LLVM 3.0 encore, sans parler de l'ARC de soutien. Cela a besoin de changer vite parce que le soutien de promoteur de bibliothèque influence directement le taux d'adoption d'ARC. This needs to change quickly because library developer support directly influences the adoption rate of ARC.

La conversion d'app existant pour DÉCRIRE UN ARC

Il y a un app pour cela!

Bien, pour être précis il y a une option de menu dans Xcode 4.2 pour cela. Vous le trouverez si vous ouvrez votre projet dans Xcode et choisissez Révisent-> le Refacteur-> le Converti à l'ARC Objectif-C.

Vous serez présentés une liste de cibles que vous voulez convertir. Assurez-vous que vous ne choisissez pas de bibliothèque statique que vous n'avez pas écrite vous-même. Les bibliothèques statiques peuvent être reliées à app permis de l'ARC sans en fait devoir être l'ARC compatible. Bien que vous puissiez devoir faire quelques changements dans les dossiers d'en-tête de la bibliothèque. Plus sur cela plus tard. Static libraries can be linked to an ARC-enabled app without actually having to be ARC compatible. Although you may have to make some changes to the library’s header files. More on that later.

“Ne peut pas Passer à l'ARC Objectif-C”

Oh cher!

La conversion dans certains cas automatique n'est pas aussi automatique que vous espéreriez que ce serait. Dans beaucoup de cas c'est à cause des bibliothèques statiques incompatibles.

Dans la plupart des cas les problèmes sont rattachés uniquement à id ou à d'autres types de flèche conservés dans un C struct, des flèches passagères sur et de C/C ++ le code ou l'utilisation de la classe NSAutoreleasePool qui n'est pas disponible en construisant un app avec l'ARC ont permis. Continué à lire pour les solutions des éditions les plus communes.

Le fait de fixer la flèche tape dans C structs

L'ARC se plaindra d'un C struct qui conserve des types de flèche :

C'est assez facile à fixer par la préattente les types de flèche avec le __ unsafe_unretained le mot clé :

Cela dit à l'ARC que la mémoire pour ces que la flèche tape est dirigée manuellement, c'est-à-dire. la voie vieille et scolaire. Désormais le type de flèche est "non retenu" par l'ARC et il est "dangereux" parce que la mémoire peut être deallocated mais la flèche n'est pas montrée au zéro automatiquement, qui peut créer peut-être une flèche se balançant. C'est la façon que cela a été tout le temps, l'ARC veut juste que vous expressément reconnaissiez que vous faites quelque chose qui est considérée dangereuse. Henceforth the pointer type is “unretained” by ARC, and it is “unsafe” because the memory may be deallocated but the pointer isn’t set to nil automatically, which can possibly create a dangling pointer. That’s the way it has been all the time, ARC just wants you to expressly admit that you’re doing something that is considered unsafe.

Si votre code a travaillé parfait auparavant, __ unsafe_unretained s'assurera simplement qu'il compile sous l'ARC. Mais pour le nouveau code vous devriez éviter de devoir utiliser ce mot clé. Une option est de changer tout C structs dans les classes Objectives-C légères avec les propriétés. One option is to change all C structs into lightweight Objective-C classes with properties.

En Fixant C/C ++ la flèche change avec les acteurs construits un pont

Dans les cas où vous passez id ou flèches d'objet sur et de C/C ++ le code, le compilateur se plaindra de la conversion et suggérera des acteurs construits un pont :

De nouveau c'est facile à fixer en jetant correctement le type de flèche et la préattente cela avec le __ le mot clé de pont :

Le __ le mot clé de pont signifie simplement que la flèche est transférée d'ou à la terre Objective-C inchangée. L'ARC ne retiendra ni, ni libérera cette flèche.

Les mots clé spéciaux __ bridge_transfer et __ bridge_retain devraient seulement être utilisés quand s'occupant du numéro vert a construit un pont sur les objets de Fondation de Base où vous devriez appeler normalement CFRetain et/ou CFRelease pour diriger la vie d'objet de Fondation de Base.

Fixer NSAutoreleasePool avec @autoreleasepool

L'ARC a remplacé la classe NSAutoreleasePool avec la directive de compilateur @autoreleasepool.

Vous devez remplacer le code en utilisant NSAutoreleasePool :

Avec le mot clé @autoreleasepool :

Les méthodes vous ne pouvez pas appeler (ou passer outre) plus

Vous devrez enlever tous les appels à ces méthodes sans substitution :

• retenir
• retainCount
• libération
• autolibération
• dealloc

Vous ne pouvez aussi utiliser le mot clé retenir avec les propriétés plus. Au lieu de cela utilisez le fort mot clé.

Vous ne pouvez plus passer outre à ces méthodes dans votre classe :

• retenir
• retainCount
• libération
• autolibération

Vous pouvez passer outre encore - (le vide) dealloc {}

Vous ne pouvez pas appeler dealloc mais vous pouvez passer outre encore le - (le vide) dealloc {} la méthode. C'est utile pour libérer la mémoire de C/C ++ les objets. Par exemple vous avez besoin d'être capables encore de libérer la mémoire d'un cas mondial Box2D. De la même façon il y a des cas où vous avez besoin de déménager moi comme le délégué d'une autre classe quand le moi la classe est deallocated. For example you still need to be able to free the memory of a Box2D world instance. Similarly there are instances where you need to remove self as the delegate of another class when the self class is deallocated.

Il y a une habitude particulière que vous avez besoin de laisser vont de. Comme vous ne pouvez pas appeler dealloc, vous ne devez pas aussi appeler [dealloc formidable]. Le compilateur produira le [dealloc formidable] l'appel en coulisses automatiquement. The compiler will generate the [super dealloc] call behind the scenes automatically.

Restriction d'appellation de propriété

Vous ne pouvez pas créer une propriété dont le nom commence "nouveau". C'est tout.

Nouveaux mots clé de Propriété : fort et faible

Le mot clé @property fort est synonyme pour retenir :

Alors que faible est semblable pour assigner, sauf qu'une faible propriété sera montrée au zéro automatiquement quand l'objet est deallocated (dorénavant : zeroing faible référence) :

Zeroing les faibles références sont disponibles seulement en visant IOS 5.0 et plus nouveau, ou Mac OS X Lion 10.7 et plus nouveau.

L'ARC défend le fait de synthétiser une propriété readonly sans qualificatif de propriété

Normalement, quand vous déclarez une propriété readonly, il n'a pas d'importance ce que le type de stockage est (retenez, assignez, la copie) depuis readonly les propriétés ne peut pas être assigné à. Prenez celui-ci par exemple :

Maintenant avec l'ARC, si vous ne déclarez pas l'ivar manuellement (@synthesize peut produire ivars) vous rencontrerez une erreur étrange sur la ligne @synthesize, en exposant :

erreur : l'ARC défend le fait de synthétiser une propriété d'un objet Objectif-C avec la propriété non indiquée ou l'attribut de stockage [4]

Aussi bizarre qu'il peut sembler, dans ce cas-là vous devrez spécifier le mot clé de stockage sur une propriété readonly, en ajoutant fort ou faible :

Cela spécifie le qualificatif de propriété de l'ivar par la déclaration @property. L'alternative devrait déclarer l'ivar manuellement, qui forcera la propriété d'utiliser le même qualificatif de propriété que l'ivar.

Pour les experts : le fait de découvrir à compile fois si l'ARC est permis

Si vous avez besoin d'apprendre si votre code est construit avec ou sans ARC, par exemple si vous êtes le promoteur d'une bibliothèque publique, vous pouvez utiliser les macros suivantes pour déterminer si l'ARC est permis à compilent le temps.

Pour les experts : permettez l'utilisation de mots clé d'ARC avec les handicapés d'ARC

Comme un auteur de bibliothèque, une des pires choses vous pourriez faire pour garantir que la compatibilité en arrière de votre bibliothèque est à #ifdef chaque mot clé spécifique de l'ARC et écrivez chaque telle ligne deux fois : une fois sans le mot clé d'ARC, une fois avec le mot clé d'ARC.

Plutôt je propose de simplement définir les mots clé d'ARC comme “noop” les déclarations quand l'ARC est non disponible. Ainsi votre code en utilisant des mots clé d'ARC compilera encore sous Xcode 4.1 ou LLVM GCC4.2 et vous n'avez besoin à #ifdef rien de rattaché à ces mots clé.

Maintenant il est sûr d'écrire le code comme cela sans tenir compte de si l'ARC est disponible ou pas, parce que les compilateurs qui ne soutiennent pas d'ARC verront seulement l'habitué (le vide *) les acteurs :

Mythe : l'ARC n'a pas été prouvé fiable

Comme si la direction de mémoire automatique a une propriété magique qui va de temps en temps dingue.

L'ARC suit encore même alloc, retenez, libérez le cycle de code Objectif-C. Il n'y a aucune ambiguïté et aucun cas spécial quand il vient à l'application de peu et de règles d'alloc-retain-release simples. C'est entièrement déterministe et le compilateur peut faire ce travail tout aussi bien, non, mieux que vous. Il n'y a rien par nature et potentiellement douteux de l'ARC. This is entirely deterministic and the compiler can do that job just as well, no, better than you. There’s nothing inherently and potentially unreliable about ARC.

Si vous avez entendu des éditions avec l'ARC, donc ils sont probablement rattachés aux situations où un ARC app les interfaces avec la Fondation de Base ou d'autre C/C ++ détermine le code. Dans ces situations vous devrez appliquer correctement les nouveaux mots clé différents (les acteurs de pont pour la plupart). Faites une erreur là et vous vous êtes reçus un problème. Mais ce n'est pas la faute d'ARC. Le même va pour retiennent des cycles, qui sont encore une possibilité dans l'ARC apps. Make a mistake there and you got yourself a problem. But that’s not the fault of ARC. The same goes for retain cycles, which are still a possibility in ARC apps.

J'ai parié aussi ma vie que la Pomme n'annoncerait pas, promouvrait et exécuterait d'ARC pour IOS et Mac OS X apps si cela n'avait pas été prouvé ferme. Si cela ne vous convainc pas, donc peut-être cette citation du promoteur d'ARC CHRIS LATTNER fait :

L'ARC est soigneusement construit pour être un modèle de programmation fiable qui fait erreur sur le côté de produire une erreur de compilateur au lieu de silencieusement produire un problème de mémoire d'exécution.

Cela explique aussi un peu pourquoi vous verrez plus (initial) compilent des erreurs avec l'ARC permis.

Mythe : l'ARC emporte le contrôle sur la direction de Mémoire

Certains soutiennent que l'ARC emporte votre contrôle sur la direction de mémoire. Cela mènerait à tour de rôle à moins que la performance d'exécution optimale. Désormais l'ARC est mauvais et devrait être évité. Henceforth ARC is bad and should be avoided.

Vous pourriez appliquer le même argument inutile à la direction assistée. Il y a certains réactionnaires qui n'auraient pas de direction assistée, juste à cause d'un sentiment subjectif du contrôle perdant. Ignorez ces gens! Pas parce qu'ils se trompent, ils sont corrects dans quelques circonstances – c'est juste que ces circonstances sont rares, très spécialisées et exigent un haut niveau d'habileté que la conservation 99 % d'utilisateurs n'ont pas simplement, ni voudraient faire de l'exercice. Ignore these people! Not because they’re wrong, they are correct in some circumstances – it’s just that those circumstances are rare, very specialized and require a high level of skill that the remaining 99% of users simply don’t have, nor would want to exercise.

Et même si vous avez vraiment les connaissances, vous êtes soumis encore aux erreurs de jugement ou à d'autres erreurs humaines. Donc même les experts profiteront d'utiliser l'ARC (ou la direction assistée d'ailleurs) dans les situations quotidiennes.

Certaines personnes qui soutiennent que l'ARC emporte le contrôle ne semblent pas comprendre ce que l'ARC fait. La direction de mémoire est de la vie d'objets, si la direction de mémoire est automatisée avec l'ARC ou le manuel. Si la vie d'un objet est partout dans la scène entière (la vue, le niveau, app, et cetera) alors que l'objet est alloué une fois quand la scène est initialisée et deallocated quand la scène est deallocated. Si vous le faites manuellement, ou automatiquement, les résultats dans le même comportement de l'application. If an object’s lifetime is throughout the entire scene (view, level, app, etc) then that object is allocated once when the scene is initialized, and deallocated when the scene is deallocated. Whether you do this manually, or automatically, results in the same behavior of the application.

Chacun a besoin de penser que l'ARC est déterministe. Il ne doit pas être confondu avec la collection d'ordures! Les cycles de collection d'ordures peuvent verser la quote part à n'importe quel moment au hasard à temps quand l'éboueur trouve nécessaire de libérer un peu de mémoire. Dans l'environnement recueilli des ordures, tel que C#, vous perdez vraiment un peu de contrôle sur la direction de mémoire et dans quelques situations cela mène à la performance d'exécution instable. Mais pas avec l'ARC. Garbage collection cycles can kick in at any random moment in time when the garbage collector finds it necessary to free up some memory. In a garbage collected environment, such as C#, you do lose some control over memory management and in some situations this leads to unsteady runtime performance. But not with ARC.

Dire que l'ARC enlève le contrôle sur la direction de mémoire est juste simple faux et probablement fondé dans l'idée que l'ARC soit égal à la collection d'ordures. Il peut provenir aussi de “faux positives” que le Bruit métallique que l'Analyseur Statique produit, qui peut avoir inculqué le doute des technologies de Bruit métallique "automatisées" en général, même si l'analyse statique et l'ARC sont des morceaux complètement séparés de technologie.

En tout cas, dans certains cas vous auriez besoin d'exercer le contrôle sur la direction de mémoire et avec l'ARC vous pouvez le faire encore, d'habitude avec les nouveaux mots clé d'ARC forts et faibles, aussi bien que construire un pont sur les acteurs pour les flèches qui traversent des limites d'ou à C/C ++ la terre. Aussi longtemps que vous êtes conscients de la vie de vos objets vous n'aurez aucun problème en influençant comment la vie d'objets est dirigée par l'ARC.

L'ARC alloue toujours et libère la mémoire d'un objet au même point à temps dans la même situation (déterministe). Ainsi l'Objectif-C avec l'ARC ne peut pas être comparé en langues recueillies d'ordures comme C#. Si vous voyez quelqu'un comparer l'ARC avec C#, envoyez-leur s'il vous plaît ce lien. If you see someone comparing ARC with C#, please send them this link.

Documentation de Référence d'ARC et articles rattachés

En lisant plus loin pour ceux qui veulent apprendre plus de l'ARC en détail.

• Bruit métallique : documentation de Compte de Référence Automatique
• Pomme : le fait de Traverser pour DÉCRIRE UN ARC des Notes de Libération
• Pomme : Xcode Nouveau Guide d'Utilisateur de Traits : Compte de Référence Automatique
Automatic Reference Counting
• Mike Ash : vendredi Q&A du Compte de Référence Automatique
• StackOverflow : Comment le compte de référence automatique travaille-t-il ?
• StackOverflow : Quels sont les avantages et les inconvénients d'utiliser l'ARC ?
• StackOverflow : Quelle est la différence entre le compte de référence automatique et la collection d'ordures ?
• informIT : Objectif-C de Comptant de Référence Automatique, la Partie 1
• informIT : l'Objectif-C de Comptant de Référence Automatique, la Partie 2 Les Détails
• Mike Ash : Zeroing les faibles références sans ARC
• Github : le Soutien en faveur de faibles références zeroing sur IOS 4 / OS X 10.6

Faites-moi savoir s'il vous plaît si j'ai oublié d'ajouter n'importe quoi de l'ARC! Surtout si vous croyez que cela devrait être knowlARCdge commun. Et n'oubliez pas de regazouiller cet article si vous l'aimez, merci! And don’t forget to retweet this article if you like it, thanks!

Suivez @gaminghorror

Suivez @kobold2d

Cet article vous a été apporté par... Je passe beaucoup de temps trouvant des idées qui vous aideront à devenir un meilleur promoteur app. J'apprécie beaucoup le processus d'apprentissage, le fait de pousser de limites (mien et vôtre et cette de technologie), en ayant la liberté de poursuivre ce qui est sur mon esprit, à hardiment le programme ce que personne n'a programmé auparavant et écrire de ce que j'ai appris. Aidez-moi à vous aider en parcourant les produits dans le fait d'Apprendre le Magasin de Cocos2D. Help me help you by browsing the products in the Learn Cocos2D Store. Vous pouvez montrer aussi votre (beaucoup apprécié!) la générosité en m'envoyant un cadeau.