[RESOLU] Installation Bibliothèque SDL (sous XCODE)
Keihilin
Membre
Hello,
Pour ceux qui n'ont pas suivi mon précèdent topic, je débute en programmation C en suivant le livre/TUTO : LE SITE DU ZERO.
Le livre est bien, la communauté très sympa, mais faut reconnaitre qu'ils sont plutôt axès PC (Windows et Linux) .. du coup mes questions spécifiques MAC & XCODE 4 ne trouve que peu d'écho..
Après avoir fini par obtenir un code qui me convient sur le TP "le PENDU. (voir mon précèdent topic toujours..)
J'attaque la partie : "Création de jeux 2D en SDL"
1ere étape "installer SDL", dans le livre (pas présent dans la tuto en ligne malheureusement) il y est expliqué comment installer cette bibliothèque.. pour différentes machines et IDE (PC, MAC, XCODE, Code:Blocks, etc..)
Seulement voila, soit je suis une tanche (très vraisemblable..), soit il manques des infos dans le tuto, mais à la fin de l'installation je me retrouve avec 9 erreurs détectés dans le SDLMain.c, principalement a propos d'un certain item : ARC ..
Réponses
Hello
Alors :
Merci ! Réactivité / Efficacité.
je sens que je vais me plaire ici ;o)
A bientôt, je sens que je vais pas tarder a être bloqué encore.. ;o)
MMmmmh mais pour développer en SDL j'utilisais plutot codeblocks enfin je sais pas si ca change énormément
Mais tu es un aventurier a ce que je vois
Si tu pouvais marque résolu dans le titre bah quand le post est resolu tout simplement ca aiderai les autres futurs aventuriers
Fait ;o)
Aventurier ? parce que j'utilise XCODE au lieu de CODEBLOCK ?
Disons que je suis sur MAC j'utilise ce qui est proposé ;o)
C'est bien un forum dédié COCOA (mac) ici non ? on est donc entouré d'aventuriers ;o)
Je pense que Am_Me te qualifiait d'aventurier car tu utilises SDL avec Xcode.
SDL est une bibliothèque crossplateforme pour faire des graphismes et de l'UI. Quand on utilise Xcode, en général c'est pour faire des applications Cocoa plutôt que du SDL. Mais bon, je dis ça parce que quand on utilise Xcode, on est sur Mac, et quand on est sur Mac, souvent on préfère faire du Cocoa. Et quand on fait du SDL, c'est qu'on fait du dev crossplateforme, donc qu'on va sans doute avoir besoin de tester son application sur Mac, Windows et Linux, et donc ça peut avoir du sens d'utiliser un IDE crossplateforme.
En pratique, rien n'empêche en pratique d'utiliser Xcode pour faire du SDL, c'est une librairie comme une autre, et on peut faire du C ou du C++ avec Xcode on est pas obligé de faire que de l'Objective-C ou du Cocoa, c'est juste pas habituel de faire du SDL plutôt que du Cocoa
Tiens, tu t'es mis à ARC Ali?
Ok je comprend mieux, en fait j'utilise SDL car c'est ce qui est expliqué dans le TUTO du SITE DES ZERO.
Et merci pour ton message j'arrive a mieux cerner ce qu'est le COCOA, un autre framework donc ?
Je pensais que COCOA était "quelque chose" qu'on utilisait en Objective-C.
Je ne vois pas trop ce que vient faire la question dans ce topic, mais oui finalement je m'y suis mis
Réticent au départ car j'aime bien tout contrôler et aimais bien maà®triser mes retain et release pour les balancer l'un l'autre proprement, en pratique j'ai été moi-même surpris à quel point je l'ai adopté si facilement et ai apprécié d'y passer.
Maintenant je ne m'en passe plus, d'autant que cela apporte un confort non négligeable, en particulier sur le fait de ne plus avoir à implémenter le dealloc et d'avoir bcp moins de choses rébarbatives à écrire. Aujourd'hui, si je veux faire juste une classe groupant des propriétés un peu comme je ferais une struct, j'ai juste à écrire @interface, toutes les @property que je veux, @end et c'est fini. Plus besoin de @synthesize dans le @implementation grâce à l'Auto-Synthesized Properties et plus besoin d'écrire le dealloc avec ARC...
Au point que si avant je n'utilisais jamais la méthode "new" car je trouvais qu'elle "cachait" l'usage du alloc et donc risquais de nous faire oublier le release, maintenant j'utilise ce "[MaClasse new]" aussi de temps en temps.
Le confort que cela fait gagner m'a fait oublier mon côté perfectionniste à vouloir mettre explicitement les retain/release manuellement, en + c'est plus efficace (car ARC optimise ces retain/release, puisqu'il gère tout il va plutôt éviter de mettre un autorelease dans une méthode A et mettre à la place un simple release dans la méthode B qui appelle cette méthode A, pour réduire l'empreinte mémoire et l'utilisation inutile de l'@autoreleasepool dans ce cas...) et au final si avant j'étais réticent à y passer je suis surpris moi-même de voir que maintenant je ne peux plus m'en passer ^^
SDL est une librairie graphique qui a été développée par la communauté dans le but d'avoir une lib OpenSource et CrossPlateforme pour dessiner des choses à l'écran.
Il existe des librairies de plus haut niveau pour carrément gérer des composants graphiques (boutons, labels, ...), certaines utilisant certainement SDL sous le capot, d'autres utilisant autre chose
Cocoa quand à lui est un framework, ou plutôt est un terme utilisé pour regrouper un ensemble des frameworks Apple pour développer sous MacOSX ou iOS (pour iOS, on parle plutôt de CocoaTouch, puisqu'il y a des frameworks qui ont été adaptés pour l'aspect tactile de l'iPhone/iPad là où sous OSX cette notion est absente). Cocoa regroupe par exemple des frameworks comme AppKit (pour OSX) / UIKit (pour iOS), qui te fournissent des widgets / contrôles comme des boutons, des vues pour afficher des images (NSImageView/UIImageView), des composants pour afficher du texte, voire pour en saisir (TextFields), ... Il y a d'autres frameworks pour tout ce qui est par exemple gestion des vidéos ou du son, d'autres pour tout ce qui est calcul vectoriel ou mathématique, d'autres pour tout ce qui est réseau...
Cocoa est donc un ensemble de bibliothèque, regroupant un nombre conséquent des classes, tant pour faire de l'UI que pour faire du métier, des requêtes réseau ou manipuler des fichiers. Par exemple dans le monde Windows, il existe DotNet (".NET") qui est un peu l'équivalent, puisqu'il regroupe plein de librairies et de classes pour te fournir des fonctionnalités graphiques, des composants comme des boutons, des classes pour gérer le réseau... donc si cela te parle, tu peux dire que "Cocoa" est à MacOSX ce que ".NET" est à Windows.
Objective-C quand à lui est le langage de programmation avec lequel on code, comme le sont le C, le Java, le C# ou le C++
Tous MacOSX est basé sur Cocoa, et tout iOS est basé sur CocoaTouch. Par exemple le Finder, la plupart des applications Apple ou même des applications tierces parties. Les librairies/frameworks présentes dans Cocoa te fournissent tout ce qu'il faut pour faire les tâches diverses et variées et interagir avec OSX (ou iOS si tu codes pour iOS avec CocoaTouch). Ce qui fait que si tu veux créer des applications pour MacOSX ou pour iOS, tu as tout intérêt à utiliser Cocoa (ça serait stupide d'utiliser autre chose si tu te restreins à OSX ou iOS, à vrai dire). Par exemple dans Cocoa les composants graphiques comme les boutons sont ceux de OSX ; de même dans CocoaTouch, les composants graphiques comme la TabBar ou la NavigationBar sont ceux fournis par Apple et utilisés partout dans iOS.
Tu peux utiliser autre chose si vraiment tu y tiens.
- Si tu n'as pas besoin d'UI (tu codes un logiciel en ligne de commande que tu vas exécuter par le terminal par exemple) et veut faire un truc portable et n'a pas besoin de fonctionnalités propres à OSX (genre l'accès au Keychain ou au système de préférences fourni par Apple ou aux librairies audio fournies dans Cocoa...) tu peux par exemple coder en C et n'utiliser aucun framework particulier, juste les fonctions standard du C. Ou utiliser une librairie C qui va te fournir les fonctionnalités dont tu as besoin.
- Si tu as besoin d'UI, mais que tu veux coder un logiciel crossplateforme, qui aura pour vocation de tourner à la fois sur OSX mais aussi sur Linux ou WIndows, alors évidemment Cocoa n'existant pas sur ces 2 autres plateformes, il ne conviendra pas. Tout comme le framework .NET de Microsoft ne conviendrait pas car il est restreint à Windows.
Tu as alors des frameworks alternatifs. SDL en est un (quoique ça fait longtemps que je me suis pas plongé dans SDL mais il me semble qu'il est surtout orienté graphisme / UI et un peu audio, et codé en C, donc suis pas les paradigmes de la Programmation Orienté Objet et ne fournit pas le nécessaire pour les autres fonctionnalités comme accès disque, requête réseau...), QT en est un autre, et ce ne sont pas les seuls.
Si tu veux juste faire du développement OSX ou si tu veux développer pour iOS, c'est Cocoa qu'il te faut apprendre.
Si tu veux faire un logiciel crossplateforme, personnellement je te conseillerai à la limite plutôt QT (qui est assez connu, bien documenté, crossplateforme et plutôt éprouvé) que des choses comme SDL.
SDL est plutôt orienté à la limite si tu veux coder un petit jeu où tu n'auras pas besoin de boutons mais juste de dessiner des choses à l'écran et jouer du son. Et encore, à ce tarif-là , mieux vaut sans doute directement apprendre OpenGL. Mais bon pour commencer dans tous les cas ces 2 là ne sont pas une mince affaire, et faire une application Cocoa avec une petite interface graphique sympa est beaucoup plus abordable.
Pour SDL, on n'a pas forcément le choix. Je travaille sur un émulateur Atari multi-plateforme et pratiquement SDL s'impose. Enfin, quand je dis que je travaille, pour l'instant j'ai juste rendu opérationnel l'affichage de l'aide en ligne sur Mac. J'ai pris l'émulation en marche!
Mais pour apprendre la programmation sur Mac, ou la programmation en général, commencer par SDL c'est hardu, c'est loin d'être le chemin facile !
C'est du C relativement bas niveau (dans le sens où il n'y a pas une UI avec des boutons, qui changent d'état quand on clique dessus avec la souris, et un évènement qd on a cliqué sur le bouton et tout... de mémoire c'est juste du "dessine moi un rectangle ici" plutôt), ce n'est pas du tout intégré à l'environnement (que ce soit MacOSX ou WIndows ou Linux) contrairement aux frameworks dédiés à chaque plateforme (comme Cocoa pour OSX, CocoaTouch pour iOS, .NET pour Windows, Gnome ou autre pour Linux, ou QT qui est crossplateforme mais fournit quand même un paquet de contrôles graphiques et de quoi faire une UI)...
Bref avec SDL faut un peu tout faire soi-même. Et utiliser un truc comme SDL pas complètement intégré à OSX plutôt que d'utiliser Cocoa, pour commencer et débuter et apprendre c'est déjà se mettre un niveau de difficulté supplémentaire
Bon a savoir mais du coup faut développer sur les trois plateformes avec 3 codes différents je ne savais pas Merci
Ok ok ;o)
Bah je me dis : Si je m'en sors avec le SDL c'est que ca devrait aller par la suite avec COCOA ;o)
Une fois le TUTO terminé, je vais m'y mettre au COCOA.
A ce moment la, j'aurais plein de nouvelles questions pour vous ;o)
Je ne suis pas très d'accord avec Ali.
Certes, avec SDL c'est du C pur et dur, mais n'est-ce pas ce qu'on attend d'un tuto sur le langage C ? Dans l'absolu, ça me semble être une bonne école de la programmation.
Et en même temps, programmer Cocoa requiert rarement une connaissance approfondie du langage C. (Mais c'est outil qui te permettra de te sortir de n'importe quelle situation ou presque).
de mémoire il me semble que dans le désert quelqu'un a dit "Dessine moi un mouton" (ça marche ni en C ni en ObjC).
Vrai! et je m'y perds un peu dans SDL >:(