Il n'est pas exagéré de dire que le SDK de l'iPhone et l'App Store ont changé à jamais la façon dont les applications mobiles sont développés et vendus. En construisant le SDK de l'iPhone sur les bases jetées par NeXT avec NeXTSTEP, qui devint plus tard framework Cocoa d'Apple pour développer des applications de bureau, Apple a été en mesure de fournir aux développeurs tiers de leur plate-forme mobile de nouvelles avec des outils et des API qui avait déjà le bénéfice de plus de 20 ans d'utilisation, les tests et la documentation. Bien que iOS, bien sûr, contient une grande quantité de code nouveau, conçu spécifiquement pour répondre aux besoins d'une touche à base plate-forme informatique mobile, de nombreuses classes qui implémentent le comportement fondamental dans le SDK iOS ont été en usage régulier depuis la fin des années 1980 ; ce code est extraordinairement robuste et parfaitement documenté.
Mais une plate-forme mobile est différent d'un ordinateur de bureau ou ordinateur portable à bien des égards, et pas tous de la technologie qui rend l'iPhone est aussi bien documenté ou bien compris que les classes bases héritées de NeXTSTEP. Une telle technologie est OpenGL ES, une bibliothèque graphique conçue pour une utilisation sur des appareils plus petits, avec une puissance de traitement limitée et de la mémoire (l'ES stands pour les systèmes embarqués). Bien que l'iPhone, iPod touch et iPad sont, à bien des égards, merveilles d'ingénierie, ils sont encore considérablement par rapport aux ordinateurs portables de faible puissance aujourd'hui et les ordinateurs de bureau. Ils ont moins de RAM, des processeurs plus lents avec des cœurs de traitement moins, et un GPU moins puissant que même peu coûteux ordinateurs d'usage général. applications iOS, tels que des jeux, qui veulent exploiter pleinement les capacités graphiques de l'iPhone ont généralement d'utiliser OpenGL ES pour obtenir les meilleures performances possibles de la quincaillerie.
Pourtant, si vous allez à la recherche d'spécifiques de niveau débutant informations sur la façon d'utiliser OpenGL ES sur l'iPhone, il peut être difficile à trouver. Bien qu'il existe un grand nombre des livres, des tutoriels et d'articles sur OpenGL, OpenGL ES qui est un sous-ensemble, presque tous on commence à enseigner quelque chose appelé mode direct, qui n'existe pas dans OpenGL ES (ou la plus récente spécification d'OpenGL, pour cette matière). Le mode direct est l'une des premières façons d'interagir avec OpenGL, mais ce n'est pas beaucoup utilisée en pratique car il est lent. En mode direct, vous effectuez un appel de fonction C séparée pour chaque pièce unique de données ou des instructions dont vous avez besoin pour passer en OpenGL. Pour dessiner un triangle, par exemple, vous avez à faire quatre appels de fonction (en plus de tout code de configuration), un appel à définir l'emplacement de chacun des trois points qui forment le triangle, puis un autre appel de fonction pour dessiner la réalité triangle. Pour les objets complexes, le code en mode direct devient rapidement fastidieuse et inefficace.
Le mode direct a été maintenu en poste de travail OpenGL pour de nombreuses années passé quand il était une option viable, pas seulement pour la compatibilité descendante, mais aussi parce qu'il était un formidable outil d'apprentissage. En ayant à briser le processus de dessin vers le bas dans tous ces appels de fonction individuelles, le programmeur qui est nouveau à la programmation graphique et les mathématiques de dessin est capable de conceptualiser ce qui se passe plus facilement. Après avoir passé quelques temps avec le mode direct, de nouveaux développeurs peuvent commencer à comprendre comment fonctionne OpenGL; au moment où ils sont initiés aux méthodes plus efficaces de transmettre des informations à OpenGL, ils ont une bonne base et sont prêts pour les techniques conceptuellement difficile.
Sans le mode direct, les programmeurs de nouvelles OpenGL ES sont obligés de commencer à utiliser ces techniques difficiles immédiatement. Il n'y a aucune entrée progressive dans la piscine OpenGL ES: vous avez juste à sauter à droite dans la partie profonde. Et si vous n'avez pas déjà de savoir nager, sauter dans la partie profonde peut être assez intimidant.
Pour aggraver les choses, de profiter pleinement de la puissance des appareils d'aujourd'hui iOS, vous devez utiliser OpenGL ES 2.0 et OpenGL ES 2.0 a une courbe d'apprentissage encore plus raide que les versions précédentes. OpenGL ES 2.0 a supprimé le support de quelque chose appelé rendu canalisation fixe qui a fourni un certain nombre d'appels de fonctions pour la manipulation des stocks tâches courantes telles que la mise en place des lumières, le déplacement et rotation des objets, et de définir la partie du monde à être rendus. Sous le pipeline fixe, par exemple, si vous voulez faire pivoter un objet, vous pouvez tout simplement appeler la fonction intégrée glRotatef() avant de tirer, ce qui serait dit OpenGL ES dans quelle mesure et sur ce que l'axe pour faire pivoter l'objet avant de le dessiner. En mettant l'accent OpenGL ES sur le rendement, une fois que le pipeline programmable a été introduit en OpenGL ES 2.0, le soutien pour le pipeline fixe a été complètement abandonné, ce qui signifie toutes ces méthodes pratiques pour la mise en place et déplacer des objets autour de votre scène sont allés. OpenGL ES 1.1 Les demandes ne seront même pas compilable sous OpenGL ES 2.0. Non seulement est OpenGL ES 2.0 à la fin profonde de la piscine, c'est la fin profonde d'une piscine très profonde, très large, et très froid.
Une des difficultés à écrire un livre sur le niveau d'introduction OpenGL ES est de choisir ce qu'il faut couvrir. Le sujet est vaste. Les livres officiels OpenGL représentent à eux seuls plusieurs milliers de pages de documents, et ceux qui supposent généralement un certain niveau de mathématiques et connaissances existantes programmation graphique. Il n'ya tout simplement aucun moyen de couvrir le sujet de manière exhaustive dans un seul livre. Une de mes frustrations personnelles lorsque l'origine apprendre la programmation graphique était l'hypothèse la plupart des livres semblait avoir que vous avez déjà eu une fondation très solide en mathématiques et que l'information était encore fraîche dans votre esprit. Je ne vais pas faire cette supposition. Je ne vous attendez pas à avoir reçu un doctorat en mathématiques avant de lire ce livre et l'écriture de votre première application OpenGL ES. Cependant, parce que la programmation graphique est donc fortement tributaire des mathématiques, vous avez besoin d'une connaissance de travail de base en mathématiques de niveau secondaire, la géométrie et la trigonométrie de base en particulier.
Que je ne vais pas faire est d'utiliser C + +.
Je sais que de nombreux livres OpenGL ES et d'autres ressources utilisez C + +, et même opérer sous l'hypothèse que le choix d'autres langues serait insensé. Pour la programmation iOS, c'est tout simplement une hypothèse erronée.
Objective-C est la lingua franca de développement iPhone. Le framework Cocoa Touch est toute écrite en Objective-C, comme le sont les objets de fondation, vous aurez besoin pour passer à la plupart des API iOS. Il est vrai que l'Objective-C et C + + code peuvent travailler ensemble en utilisant quelque chose qui s'appelle Objective-C + + et Objective-C + + est un étonnant morceau de l'ingénierie. Mais il a aussi été décrit comme un «mariage contre nature» et un «mariage de complaisance" par les ingénieurs de l'équipe du compilateur d'Apple. C'est une excellente ressource si vous avez de grandes bibliothèques existantes de code C + + ou si vous êtes le portage quelque chose qui a été écrit en C + + d'une autre plateforme. Mais si vous partez de zéro sur l'iPhone, Objective-C est vraiment le chemin à parcourir.
La raison pour laquelle l'Objective-C + + est un «mariage impie" C'est parce que les deux langues ont évolué à partir de sources très différentes et utilisent des modèles d'objets très différents. C + + utilise un modèle d'objet dérivé d'un langage de programmation appelé Simula. Simula dérivé des langages comme C + + sont fortement typés et l'utilisation de répartition statique, ce qui signifie que de déterminer comment une fonction membre est appelée arrive au moment de la compilation. Fondamentalement, C + + fait beaucoup de contrôles et de règles d'application au moment de la compilation, en limitant ce que vous pouvez faire pour vous empêcher de vous tirer dans le pied. Objective-C, d'autre part, utilise un modèle objet basé sur Smalltalk, qui est faiblement typé dynamiquement et expédiés. Objective-C est beaucoup plus permissif, et diffère de nombreuses tâches à l'exécution que C + + poignées à la compilation. Il existe des arguments pour les deux approches --- ainsi que des moments où il est clairement un meilleur choix --- mais quelque façon que vous le regardez, ils sont fondamentalement différentes langues, bien plus que les différences syntaxiques. En conséquence, vous avez tendance à utiliser des modèles radicalement différents lors de l'utilisation des deux langues.
Les raisons les plus souvent donnés pour l'utilisation de C + + sont les performances et la portabilité. Quand il s'agit de performance, il est vrai que C + + a un peu moins frais généraux quand il s'agit de création d'objet et de la destruction par rapport à l'Objective-C d'allocation et désallocation, ainsi que d'un peu moins frais généraux quand il s'agit de fonctions membres appelant par rapport à l'objectif -C 's mécanisme de distribution dynamique. Toutefois, dans les deux cas, le surcoût est plus que d'utiliser les fonctionnalités de bas niveau C que les deux langues se reposer sur le dessus de. Par exemple, free() malloc() est moins coûteux que ce soit C + + 's new ou Objective-C alloc and init. Lorsque le rendement est potentiellement un problème (et la performance est souvent un problème potentiel lorsque vous faites la programmation graphique sur un appareil embarqué), je vais éviter le surcoût du modèle objet complètement et d'utiliser C. Puisque les deux droites Objective-C et C + + sont des supersets C, C code peut être utilisé à la fois dans C + + et Objective-C sans aucune transition ou l'impiété du tout. Quant à la portabilité, il est vrai que C + + est toujours une langue plus communément utilisés que Objective-C, mais combien d'une question qui est dans l'espace mobile, où Java est le langage suivant le plus couramment utilisé après l'Objective-C, est discutable .
Mais une plate-forme mobile est différent d'un ordinateur de bureau ou ordinateur portable à bien des égards, et pas tous de la technologie qui rend l'iPhone est aussi bien documenté ou bien compris que les classes bases héritées de NeXTSTEP. Une telle technologie est OpenGL ES, une bibliothèque graphique conçue pour une utilisation sur des appareils plus petits, avec une puissance de traitement limitée et de la mémoire (l'ES stands pour les systèmes embarqués). Bien que l'iPhone, iPod touch et iPad sont, à bien des égards, merveilles d'ingénierie, ils sont encore considérablement par rapport aux ordinateurs portables de faible puissance aujourd'hui et les ordinateurs de bureau. Ils ont moins de RAM, des processeurs plus lents avec des cœurs de traitement moins, et un GPU moins puissant que même peu coûteux ordinateurs d'usage général. applications iOS, tels que des jeux, qui veulent exploiter pleinement les capacités graphiques de l'iPhone ont généralement d'utiliser OpenGL ES pour obtenir les meilleures performances possibles de la quincaillerie.
Pourtant, si vous allez à la recherche d'spécifiques de niveau débutant informations sur la façon d'utiliser OpenGL ES sur l'iPhone, il peut être difficile à trouver. Bien qu'il existe un grand nombre des livres, des tutoriels et d'articles sur OpenGL, OpenGL ES qui est un sous-ensemble, presque tous on commence à enseigner quelque chose appelé mode direct, qui n'existe pas dans OpenGL ES (ou la plus récente spécification d'OpenGL, pour cette matière). Le mode direct est l'une des premières façons d'interagir avec OpenGL, mais ce n'est pas beaucoup utilisée en pratique car il est lent. En mode direct, vous effectuez un appel de fonction C séparée pour chaque pièce unique de données ou des instructions dont vous avez besoin pour passer en OpenGL. Pour dessiner un triangle, par exemple, vous avez à faire quatre appels de fonction (en plus de tout code de configuration), un appel à définir l'emplacement de chacun des trois points qui forment le triangle, puis un autre appel de fonction pour dessiner la réalité triangle. Pour les objets complexes, le code en mode direct devient rapidement fastidieuse et inefficace.
Le mode direct a été maintenu en poste de travail OpenGL pour de nombreuses années passé quand il était une option viable, pas seulement pour la compatibilité descendante, mais aussi parce qu'il était un formidable outil d'apprentissage. En ayant à briser le processus de dessin vers le bas dans tous ces appels de fonction individuelles, le programmeur qui est nouveau à la programmation graphique et les mathématiques de dessin est capable de conceptualiser ce qui se passe plus facilement. Après avoir passé quelques temps avec le mode direct, de nouveaux développeurs peuvent commencer à comprendre comment fonctionne OpenGL; au moment où ils sont initiés aux méthodes plus efficaces de transmettre des informations à OpenGL, ils ont une bonne base et sont prêts pour les techniques conceptuellement difficile.
Sans le mode direct, les programmeurs de nouvelles OpenGL ES sont obligés de commencer à utiliser ces techniques difficiles immédiatement. Il n'y a aucune entrée progressive dans la piscine OpenGL ES: vous avez juste à sauter à droite dans la partie profonde. Et si vous n'avez pas déjà de savoir nager, sauter dans la partie profonde peut être assez intimidant.
Pour aggraver les choses, de profiter pleinement de la puissance des appareils d'aujourd'hui iOS, vous devez utiliser OpenGL ES 2.0 et OpenGL ES 2.0 a une courbe d'apprentissage encore plus raide que les versions précédentes. OpenGL ES 2.0 a supprimé le support de quelque chose appelé rendu canalisation fixe qui a fourni un certain nombre d'appels de fonctions pour la manipulation des stocks tâches courantes telles que la mise en place des lumières, le déplacement et rotation des objets, et de définir la partie du monde à être rendus. Sous le pipeline fixe, par exemple, si vous voulez faire pivoter un objet, vous pouvez tout simplement appeler la fonction intégrée glRotatef() avant de tirer, ce qui serait dit OpenGL ES dans quelle mesure et sur ce que l'axe pour faire pivoter l'objet avant de le dessiner. En mettant l'accent OpenGL ES sur le rendement, une fois que le pipeline programmable a été introduit en OpenGL ES 2.0, le soutien pour le pipeline fixe a été complètement abandonné, ce qui signifie toutes ces méthodes pratiques pour la mise en place et déplacer des objets autour de votre scène sont allés. OpenGL ES 1.1 Les demandes ne seront même pas compilable sous OpenGL ES 2.0. Non seulement est OpenGL ES 2.0 à la fin profonde de la piscine, c'est la fin profonde d'une piscine très profonde, très large, et très froid.
Ne vous inquiétez pas si vous ne comprenez pas ce que le pipeline est, ou quelle est la différence entre un fixe et d'un pipeline programmable. Cela sera expliqué dans les chapitres à venir.Pensez à ce livre comme un gilet de sauvetage pour l'OpenGL ES 2.0. Vous allez toujours avoir à sauter dans le grand bain dès le début, mais je devrais être capable de garder la tête hors de l'eau la plupart du temps.
Qu'est-ce que vous devez savoir
Pour utiliser ce livre, vous n'avez pas besoin de connaître déjà quelque chose sur OpenGL, OpenGL ES, ou même sur la programmation graphique en général. Vous aurez cependant besoin de comprendre les bases de la programmation et, plus particulièrement, la programmation en Objective-C pour les appareils iOS. Cela signifie que vous aurez besoin d'être à l'aise avec les langues Objective-C, ainsi que droites C. Vous devriez avoir une certaine familiarité avec les divers cadres qui composent le SDK de l'iPhone et se familiariser avec les concepts de programmation de base, y compris la gestion de la mémoire. Bien que je vais aller lentement que je vous présenter les concepts 3D, je ne serai pas expliquer des concepts de programmation de base tels que la différence entre l'allocation de mémoire sur la pile et sur le tas. Si vous êtes rouillé ou de doute, c'est une bonne idée de rafraîchir sur les bases de programmation avant de procéder. Vous devez également être familiarisé avec les bases du travail dans Xcode.Une des difficultés à écrire un livre sur le niveau d'introduction OpenGL ES est de choisir ce qu'il faut couvrir. Le sujet est vaste. Les livres officiels OpenGL représentent à eux seuls plusieurs milliers de pages de documents, et ceux qui supposent généralement un certain niveau de mathématiques et connaissances existantes programmation graphique. Il n'ya tout simplement aucun moyen de couvrir le sujet de manière exhaustive dans un seul livre. Une de mes frustrations personnelles lorsque l'origine apprendre la programmation graphique était l'hypothèse la plupart des livres semblait avoir que vous avez déjà eu une fondation très solide en mathématiques et que l'information était encore fraîche dans votre esprit. Je ne vais pas faire cette supposition. Je ne vous attendez pas à avoir reçu un doctorat en mathématiques avant de lire ce livre et l'écriture de votre première application OpenGL ES. Cependant, parce que la programmation graphique est donc fortement tributaire des mathématiques, vous avez besoin d'une connaissance de travail de base en mathématiques de niveau secondaire, la géométrie et la trigonométrie de base en particulier.
Que vous devez avoir
Afin de tirer le meilleur parti de ce livre, vous devez avoir accès à un Mac à processeur Intel et d'être un membre du Programme pour développeurs iPhone d'Apple. Assurez-vous de télécharger la dernière version du SDK de l'iPhone avant de commencer. Bien que vous serez en mesure d'exécuter une grande partie du code de ce livre sur l'iPhone Simulator, pour tirer le meilleur parti de celui-ci, vous aurez besoin pour être en mesure d'exécuter des applications sur votre iPhone, iPad ou iPod touch, ainsi un des adhésions payées SDK de l'iPhone, qui vous donnent la possibilité d'exécuter des applications sur un périphérique physique, est fortement recommandée. OpenGL ES de programmation peuvent être très gourmandes en temps processeur, et le simulateur d'iPhone fonctionnant sur votre Mac ne vous donnera pas une bonne indication de la façon dont vos programmes se produiront sur un périphérique réel iOS, car tous les périphériques iOS ont un processeur plus lent et moins de RAM que même les Macs les plus bas de gamme.Remarque à propos des choix de la langue
Avant de commencer, je veux prendre un deuxième rapidement à parler de mon choix de langages de programmation. Dans ce livre, je vais être en utilisant Objective-C. Objective-C est un sur-ensemble du C, et dans beaucoup d'endroits, je vais tirer parti de ce fait et utiliser le bon vieux fonctions C, structures et types de données au lieu d'utiliser de niveau supérieur objets Objective-C.Que je ne vais pas faire est d'utiliser C + +.
Je sais que de nombreux livres OpenGL ES et d'autres ressources utilisez C + +, et même opérer sous l'hypothèse que le choix d'autres langues serait insensé. Pour la programmation iOS, c'est tout simplement une hypothèse erronée.
Objective-C est la lingua franca de développement iPhone. Le framework Cocoa Touch est toute écrite en Objective-C, comme le sont les objets de fondation, vous aurez besoin pour passer à la plupart des API iOS. Il est vrai que l'Objective-C et C + + code peuvent travailler ensemble en utilisant quelque chose qui s'appelle Objective-C + + et Objective-C + + est un étonnant morceau de l'ingénierie. Mais il a aussi été décrit comme un «mariage contre nature» et un «mariage de complaisance" par les ingénieurs de l'équipe du compilateur d'Apple. C'est une excellente ressource si vous avez de grandes bibliothèques existantes de code C + + ou si vous êtes le portage quelque chose qui a été écrit en C + + d'une autre plateforme. Mais si vous partez de zéro sur l'iPhone, Objective-C est vraiment le chemin à parcourir.
La raison pour laquelle l'Objective-C + + est un «mariage impie" C'est parce que les deux langues ont évolué à partir de sources très différentes et utilisent des modèles d'objets très différents. C + + utilise un modèle d'objet dérivé d'un langage de programmation appelé Simula. Simula dérivé des langages comme C + + sont fortement typés et l'utilisation de répartition statique, ce qui signifie que de déterminer comment une fonction membre est appelée arrive au moment de la compilation. Fondamentalement, C + + fait beaucoup de contrôles et de règles d'application au moment de la compilation, en limitant ce que vous pouvez faire pour vous empêcher de vous tirer dans le pied. Objective-C, d'autre part, utilise un modèle objet basé sur Smalltalk, qui est faiblement typé dynamiquement et expédiés. Objective-C est beaucoup plus permissif, et diffère de nombreuses tâches à l'exécution que C + + poignées à la compilation. Il existe des arguments pour les deux approches --- ainsi que des moments où il est clairement un meilleur choix --- mais quelque façon que vous le regardez, ils sont fondamentalement différentes langues, bien plus que les différences syntaxiques. En conséquence, vous avez tendance à utiliser des modèles radicalement différents lors de l'utilisation des deux langues.
Les raisons les plus souvent donnés pour l'utilisation de C + + sont les performances et la portabilité. Quand il s'agit de performance, il est vrai que C + + a un peu moins frais généraux quand il s'agit de création d'objet et de la destruction par rapport à l'Objective-C d'allocation et désallocation, ainsi que d'un peu moins frais généraux quand il s'agit de fonctions membres appelant par rapport à l'objectif -C 's mécanisme de distribution dynamique. Toutefois, dans les deux cas, le surcoût est plus que d'utiliser les fonctionnalités de bas niveau C que les deux langues se reposer sur le dessus de. Par exemple, free() malloc() est moins coûteux que ce soit C + + 's new ou Objective-C alloc and init. Lorsque le rendement est potentiellement un problème (et la performance est souvent un problème potentiel lorsque vous faites la programmation graphique sur un appareil embarqué), je vais éviter le surcoût du modèle objet complètement et d'utiliser C. Puisque les deux droites Objective-C et C + + sont des supersets C, C code peut être utilisé à la fois dans C + + et Objective-C sans aucune transition ou l'impiété du tout. Quant à la portabilité, il est vrai que C + + est toujours une langue plus communément utilisés que Objective-C, mais combien d'une question qui est dans l'espace mobile, où Java est le langage suivant le plus couramment utilisé après l'Objective-C, est discutable .
Aucun commentaire:
Enregistrer un commentaire