Livre de cocos2d, le Chapitre 3 : Essentiel
Le chapitre 3 – Essentiel
Ce chapitre est une référence des classes fondamentales de cocos2d et comment les utiliser. Les noeuds, les Couches, les Scènes, les Étiquettes, les Lutins, les Transitions, les Actions, vous l'appelez. Aussi CCDirector, SimpleAudioEngine et d'autres classes de singleton souvent utilisées aussi. Les concepts plus avancés seront discutés dans un chapitre dernier, Spritesheets par exemple. Also CCDirector, SimpleAudioEngine and other often used singleton classes as well. More advanced concepts will be discussed in a later chapter, Spritesheets for example.
La soumission du premier brouillon de chapitre est due suivant vendredi, le 16 juillet.
Ce qui fait vous pensez devrait être dans le Chapitre 3 ?
Savez-vous une classe cocos2d ou un processus que vous croyez est essentiel et devrait être discuté dans ce chapitre ? Faites-moi savoir!
Le résumé du fait de travailler sur le Chapitre 2 – Être commencé
Pour un j'ai exposé le projet de promotion Bonjour Mondial en détail et ai fait une modification simple en utilisant la contribution de contact. En même temps au moins un niveau de base de compréhension des classes cocos2d a été introduit mais le point essentiel de cela est fait dans le Chapitre 3. En plus, il y avait beaucoup d'aspects théoriques que j'ai voulus discuter aussi, le plus la direction de Mémoire et la mémoire disponible aussi bien que les attentes de cadre lors de l'essai sur le Simulateur contre un appareil. Et évidemment les appareils et leurs différences subtiles. J'espère vraiment que ce genre de détails sont appréciés même s'ils ne sont pas 100 % rattachés à cocos2d. Je vois régulièrement des promoteurs cocos2d se battre avec les éditions de mémoire, avec les différences inattendues sur l'appareil contre le Simulateur, ou comparer framerates du Simulateur et peut-être même le Débogage construit. Cela m'a fait vouloir s'égarer du sentier battu un moment pour avec un peu de chance sauver les lecteurs quelques idées fausses et la douleur associée à eux. In addition, there were a lot of theoretical aspects I wanted to discuss as well, most of all Memory Management and available memory as well as setting expectations on testing on Simulator vs. a device. And of course the devices and their subtle differences. I do hope that those kind of details are appreciated even if they’re not 100% related to cocos2d. I regularly see cocos2d developers struggling with memory issues, with unexpected differences on the device vs the Simulator, or comparing framerates of the Simulator and possibly even Debug builds. That made me want to stray off the beaten path for a moment to hopefully save the readers some misconceptions and the pain associated with them.
J'ai réalisé aussi par combien de pas un nouveau promoteur doit passer et combien doit apprendre là dans le cas où vous n'avez jamais travaillé avec l'I-Phone SDK auparavant. Il commence avec le fait de s'inscrire comme le promoteur d'I-Phone et ne finit pas avec le fait d'installer le SDK parce que vous avez besoin aussi des profils approvisionnants, beaucoup de trait discuté et pénible. Pour tout cela j'ai fait allusion à existant (et excellent) la documentation de Pomme. Typiquement le changement de processus avec chaque nouvel I-Phone que SDK ou peut même être sous NDA, ainsi en discutant comment tout cela travaille avec l'I-Phone SDK 4 ne serait pas une bonne idée comme peu de temps après le livre est sorti l'I-Phone SDK 5 peut venir, en introduisant des changements dans le Portail de Promoteur et iTunes Communiquent avec cela. Il m'a vraiment reçu l'idée et je sais que d'autres l'ont aussi, que nous avons besoin d'une Classe de travaux dirigés de mains de l'exploitation qui prend un par les pas de s'inscrire comme le Promoteur d'I-Phone à l'édition de son premier App, en faisant allusion à la documentation officielle correcte pour chaque pas en n'oubliant pas des écueils communs qui ne sont pas dans les docteurs officiels. For all of this I refered to existing (and excellent) Apple documentation. Typically the processes change with each new iPhone SDK or may even be under NDA, so discussing how all of this works with iPhone SDK 4 wouldn’t be a good idea since shortly after the book is out iPhone SDK 5 may be coming, introducing changes to the Developer Portal and iTunes Connect with it. It did get me the idea, and I know others have it too, that we need some holding-hands Tutorial which takes one through the steps from registering as iPhone Developer to publishing one’s first App, by referring to the correct official documentation for each step while not forgetting about common pitfalls that are not in the official docs.
J'ai remarqué aussi comment facile cela peut devoir donner comment vous introduisez subitement un nouveau concept sans l'expliquer d'abord. Et ensuite vous devez décider combien de renseignements sont nécessaires pour introduire le concept sans s'égarer trop loin de ce quoi vous voulez parler en premier lieu. C'est surtout dur pour moi parce que j'ai tendance à vouloir expliquer tout en détail mais quelques choses doivent être quittées pour une discussion dernière. J'attends la réaction de la rédaction impatiemment maintenant. Il a aidé tremendeously pour le premier chapitre et j'ai appris beaucoup du personnel éditorial Apress, donc je le trouve excitant que les experts me montrent aux défauts et font des suggestions, j'entre pour les fixer et ensuite voir combien mieux c'est. C'est comment j'aime apprendre des choses et il va être un des concepts de base du livre. Montrez comment il est fait, comment il ne devrait pas être fait (s'il faisait souvent mal) et comment il peut être fait encore mieux si vous voulez éviter le problème à la longue, en expliquant pourquoi. It’s especially hard for me because I tend to want to explain everything in detail but some things have to be left for a later discussion. I’m looking forward to editorial feedback now. It has helped tremendeously for the first chapter and I learned a lot from the Apress editorial staff, so I find it exciting that the experts point me to the flaws and make suggestions, I go in to fix them and then see how much better it is. That’s how I like to learn things and it’s going to be one of the core concepts of the book. Show how it’s done, how it shouldn’t be done (if it’s often done wrong) and how it can be done even better if you want to avoid trouble in the long run, while explaining why.
Aimez-vous vraiment le livre de cocos2d, en vous demandant juste si vous pouvez ajouter plus d'informations de la partie d'accéléromètre surtout du filtre du laisser-passer bas et du filtre du haut laisser-passer.
Plus d'informations de cela à http://developer.apple.com/iphone/librar y/documentation/EventHandling/Conceptual/EventHandlingiPhoneOS/MotionEvents/MotionEvents.html
Pensez est joli utilement pour isoler la composante de gravité. En construisant un type de Raiden de jeu avec cocos2d maintenant et je trouve important d'isoler la gravité pour recevoir les X et le mouvement Y. Faites-moi savoir ce que vous y pensez ? Let me know what you think about it ?
Hong Cheng
Merci, qui est un thème intéressant effectivement! Et facilement donné qu'il y a un concept appelé la gravité affectant des données d'accéléromètre. Au moins je devrais faire une boîte de Note et montrer au lien pour les renseignements de plus. At least I should make a Note box and point to the link for further information.
Ne le mentionnez pas
Une région qui a besoin de beaucoup plus de documentation est les caractéristiques spatiales de la hiérarchie de noeud.
Le rapport entre les limites, les cadres, contentSize, escalade etc. Quel changer quand et les effets secondaires et les implications de changer chacun. Comment ils sont modifiés (si du tout) par les noeuds parentaux. Des noeuds “shrinkwrap” leurs limites autour de leurs enfants ? Questions comme ça. How they are modified (if at all) by parent nodes. Do nodes “shrinkwrap” their bounds around their children? Questions like that.
Quelques techniques de déboguant de hiérarchie de vue de discussion seraient grandes, aussi. Tel comme comment déterminer pourquoi les noeuds d'enfant ne sont pas affichés à la grandeur/position à laquelle vous vous attendez.
Vous et tous les autres semblez utiliser des scènes sparingly, le codage dur eux dans vos classes. Par exemple, dans votre code source du chapitre 3, quand vous allez à la scène de menu, vous avez un bouton pour retourner à la scène HelloWorld :
[[CCDirector sharedDirector] replaceScene : [La scène de HelloWorld]];
Mais et si je veux avoir disent 10 scènes et bougent entre eux avec le fait de piquer ou les flèches de navigation ? Je ne veux pas dur coder les scènes avancées et arrières dans chaque scène. Il serait mieux d'avoir quelque directeur de scène, sorte de pareils une scène de maître avec l'autre intérieur cela. It would be better to have some kind of scene manager, sort of like a master scene with the other inside it.
Est cela possible à avoir quelque part à l'extérieur des scènes :
CCArray NextSceneArrayOfScenes = ”Scene00 ″, ”Scene01 ″, ”Scene02 ″;
chosenScene + = 1;//l'utilisateur nagivates en avant
CCScene* nextScene = [NextSceneArrayOfScenes objectAtIndex:chosenScene];
[[CCDirector sharedDirector] replaceScene : [la scène de nextScene]];
Ou utiliseriez-vous des couches/noeuds au lieu de cela et les déplaceriez juste au côté, en simulant un changement de scène ?
Quand les gens font un magazine ou quelque chose, comment est chaque page manipulée, comme une scène ou comme les couches/noeuds ?
J'ai trouvé une classe de travaux dirigés pour un sceneManager.
http://www.iphone gametutorials.com/2010/09/07/cocos2d-menu-tutorial-part-2/
C'est assez intelligent, en créant une couche et en l'emballant dans une scène et le fait de le rendre pour être la nouvelle scène.
Il pourrait être modifié pour que le sceneManager ait une gamme de toutes les scènes possibles et la scène qui appelle le sceneManager pourrait envoyer un nombre basé sur la position actuelle (dites si vous faites un magazine ou quelque chose où les scènes sont l'équivalent de “pages”).
Cependant, quelque chose avec 50 pages aurait besoin probablement d'être manipulée encore plus efficacement, où les pages sont d'une façon ou d'une autre produites dynamiquement, en chargeant aussi le contenu dynamiquement.