[Résolu] objective-c et/ou C ?
Paul_p
Membre
Salut,
j'aurais aimé savoir si vous êtes amené à utiliser du C en faisant des appli iphone/ipod/ipad?
est-ce que le C est "presque" indispensable pour réaliser ce qu'on veut avec l'iphone, ou bien l' "objective-c" est suffisant?
par exemple, faire un jeu sur iphone, pour créer les graphismes, la 3d par exemple ou la simulation de 3, imaginons que je veuille faire une appli où on peut suivre un personnage ne train de "voler" dans les airs, pouvez-vous me dire comment réaliser ce genre de jeu?
Merci de vos réponses 8--)
j'aurais aimé savoir si vous êtes amené à utiliser du C en faisant des appli iphone/ipod/ipad?
est-ce que le C est "presque" indispensable pour réaliser ce qu'on veut avec l'iphone, ou bien l' "objective-c" est suffisant?
par exemple, faire un jeu sur iphone, pour créer les graphismes, la 3d par exemple ou la simulation de 3, imaginons que je veuille faire une appli où on peut suivre un personnage ne train de "voler" dans les airs, pouvez-vous me dire comment réaliser ce genre de jeu?
Merci de vos réponses 8--)
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Le secret de la 3D sur iDevice c'est OpenGL SE. Si tu veux plonger les mains dans le cambouis, procure-toi l'ouvrage "OpenGL 2.0 - Guide Officiel". C'est un gros pavé de 700 pages très didactique, aussi bien pour les débutants que les "pro".
j'ai vu aussi qu'il existait cocoa2D, je vais me renseigner sur open GL
sinon une fois qu'on est à l'aise avec l'obj-c, c'est à peu près abordable le C? (pour créer des jeux...)
Le C est un langage bas niveau. C'est quand même pas de l'assembleur, c'est structuré et tu retrouves des éléments de syntaxe du C quand tu écris de l'Objective-C comme les boucles for par exemple... mais ça reste plus bas niveau que l'Objective-C.
En particulier par exemple c'est à toi de gérer la mémoire, puisque tu n'as pas de mécanisme de retain-count. Tu ne peux pas créer des objets, puisque le C n'est pas un langage objet mais un langage procédural. Au lieu de cela tu alloue de la mémoire (malloc), la libère une fois fini (free), mais tu dois savoir la taille de la mémoire que tu veux allouer (sizeof...) , puis remplir cette mémoire (strcpy...).
D'un autre côté quand tu mix du C et de l'Objective-C tu peux avoir le meilleur des deux mondes, manipuler des objets Cocoa donc en Objective-C, gérer la mémoire avec les classiques retain/release & co, et récupérer de ces objets Cocoa des objets C (genre 'bytes' à partir de NSData ou autre), ou ne manipuler au niveau de l'API C que des types primitifs.
Mais ça ne reste pas trivial si tu n'as jamais fait de pur C
- Jeu 2D type plateau, avec animations relativement simples et peu nombreuses : Objective-C suffit amplement
- Jeu 2D un peu plus complexe : Cocos2D peut sans doute aider (je sais pas je l'ai jamais utilisé personnellement)
- Jeu 2D à forte dynamique RT, genre un TowerDefense ou autre où tu as des tirs qui fusent dans tous les sens et 150 sprites qui bougent dans ton viewport : vaut le coup de se pencher sur le dessin direct du jeu à l'écran (et éviter d'utiliser une UIView par sprite à animer, surtout !!! même si ça c'est conseillé d'éviter rapidement pour des fortes composantes de dessin RT). L'utilisation d'OpenGL ES peut être intéressante à ce niveau aussi.
- Jeu 3D : OpenGL ES
Dans tous les cas, pour un jeu de plateau ou un truc relativement statique, où il peut y avoir des animations certes mais qui ne consomme pas non plus un max, Objective-C et Cocoa peuvent suffire. Considérer éventuellement d'optimiser le dessin en personnalisant ses draw plutôt que de surcharger sa vue de subviews (car trop surcharger de views peut consommer des ressources... sauf qu'optimiser le dessin implique de passer par CoreGraphics pour dessiner, qui est du C...). Mais pour un jeu un peu plus consommateur de ressources ou d'une plus grande ampleur avec une forte composante graphique dynamique et temps réel (au sens technique du terme, donc avec une timeframe restrictive), OpenGL ES devient vite intéressant. Et pour de la 3D vite incontournable.
merci de toutes ces précisions en tout cas
Casse-brique, Space Invader, pac-man, pong, jeux de refléxes, tétris, columns, jeux de tir, jeux de mémoire, jeux de cartes, jeux musicaux, jeux de stratégie, etc. Tout cela est réalisable avec des UIView. On peut faire énormément de choses avec "seulement" quelques dizaines de sprites. "Faire un jeu" ce n'est pas juste afficher des sprites, mais imaginer quelque chose d'amusant. La technique est moins importante que le plaisir de jouer.
Ensuite, comme tu le disais toi-même dans un autre post, on peut employer les CALayer et les CGLayer pour améliorer l'efficacité de l'affichage. C'est plus complexe à faire, mais toujours plus facile que OpenGL ES.
Et maintenant, il y a iOS 5 avec de nouvelles API graphiques, comme les Core Images et la bibliothèque GLKit pour faciliter l'emploi d'OpenGL. Il semble même que l'on puisse dessiner des Core Images directement dans des surfaces OpenGL ! De quoi réaliser des affichages hybrides. Une possibilité fascinante !
C'est pour cela que ça dépend énormément du type de jeu que l'on souhaite réaliser. La question n'est pas tant de savoir si c'est un jeu (après tout certains jeux sont très complexes, d'autres peuvent être très simples et certaines applications juste "utilitaires" plus complexes que certains jeux... bref "jeu" ça veut rien dire pour qualifier la complexité de réalisation d'une appli)
Pour un jeu, j'aurais tendance à vouloir le porter sur plusieurs plateformes, et là , c'est C ou C++ et OpenGL.