Site News
Research
Texts
X-philo
Code
KB
Awards
Links
Site Map





Copyright (c)
2000-04
by Newsdee

   

Treize conseils pour apprendre la programmation
(en reponse a un mail de: Waren Be).

1 - Tout d'abord, je te conseillerais d'apprendre a programmer independamment du langage.

En d'autres termes, le vrai programmeur (a mon sens) maitrise l'algorithmique d'avantage qu'il maitrise les details et optimisations d'un hardware ou un langage particulier. L'exemple typique, c'est les hackers, par exemple Kevin Mitnick: la presse le montre comme un genie de la programmation, alors que lui-meme dit qu'il ne programme pas beaucoup, au contraire, il obtient ses mots de passe et acces en exploitant des failles logicielles (qu'il recherche/recherchait) et en convaincant les gens de leur donner leur password ("social engineering"). Pareil pour celui qui fait un virus: il ne fait qu'exploiter certaines failles ou techniques de pointe qui sont tres difficilement exportables ailleurs.

Le "vrai" programmeur donc reconnait que tout ca ne sont que des "details". Ca peut etre tres interessant de les explorer, mais, ca ne veut pas dire qu'on maitrise la programmation. C'est la difference entre le tailleur de pierres et l'architecte de la cathedrale: meme si le tailleur de pierre est tres performant, l'architecte a beaucoup plus de liberte d'expression. :-)

2 - Cela dit, tout depend de tes objectifs.

Personellement je voulais faire des jeux, donc me meler a la "scene" m'a donne l'opportunite d'elever la barre et c'etait un challenge a atteindre. Mais au bout d'un moment je me suis rendu compte que je passais trop de temps a essayer d'optimiser un driver graphique, alors qu'il y a des librairies toutes faites (Allegro ou SDL). [au passage, il y a un excellent compilateur gratuit pour Windows nomme dev-cpp ou dev-c++, regarde dans google]. Il faut penser ce que tu veux faire/apprendre et t'organiser en consequence.

3 - Il est donc inutile d'essayer de reinventer la roue, mais, par contre, il est tres utile de comprendre comment la roue fonctionne.

J'ai ecrit une page web il y a longtemps sur certaines techniques en assembleur: (miroir rapide sur: http://amid.free.fr/archives/graphiqu.htm). Vers la fin tu trouveras une bibliographie avec certains bouquins excellents (qui doivent etre un peu vieillots aujourd'hui). Cependant les autheurs Andre Lamothe et Michael Abrash sont excellents, et il devrait y avoir des versions en Francais. Les deux parlent de 3d et 2d tres en detail et sont faciles a suivre.

4 - Les concepts de la 3D sont independants du langage

La 3d est a la base des maths matricielles. L'idee est que chaque point est represente en trois dimensions, plus une quatrieme valeur utilisee pour "normaliser". Apres chaque mouvement (de camera, d'objet, etc) est obtenu en appliquant une matrice de transformation [1x4] a la matrice [4x1] de chaque point. Ca a l'air simple comme ca, mais apres il faut gerer plein de choses :-) Commence tranquillement avec du "fil de fer", apres tu pourras apprendre a faire le reste.

5 - La 3D est un gros mensonge

Eh oui. Les ecrans sont 2D, donc, l'astuce est de transformer ton objet pour donner une apparence 3D. Pareil pour les textures, les effets de lumiere, etc. Il y a plein de maths dans tout ca - ce qui est bon et mauvais. Mauvais car ca peut etre prise de tete parfois, mais c'est bon parce qu'une fois que tu as compris c'est tout simplement une formule a appliquer.
Encore une fois je souligne que tu devrais penser quel est ton vrai objectif: est-ce que tu veux programmer un "moteur 3D", ou bien tu veux simplement faire des demos ou des jeux? Dans le deuxieme cas, tu peux te baser dans des moteurs 3D existants (du moins au depart) et comprendre a fur a mesure.

6 - Utilise les bons outils.

SDL ou Allegro sont de tres bonnes librairies qui gerent un peu tout. DirectX et OpenGL "en brut" sont tres complexes et difficiles a maitriser pour un neophyte. L'ideal est donc une version de SDL ou Allegro qui utilise Dx ou Ogl, comme ca tu ne prends pas la tete avec les notations carambolesques de Microsoft ou de Linuxiens dechaines.

7 - Un prototype vaut mille heures de debug

N'hesite pas a faire des petits prototypes avec des langages simples (par exemple Flash MX avec Actionscript!) avant de te lancer dans un gros projet en C, C++, ou en Java. L'idee est de tester ton concept et algorithmes d'abord, meme si ca rame a mort...
Aussi pour modelliser ton programme/idee/etc, et te clarifier tes idees, il peut etre utile d'apprendre un systeme de notation comme l'UML (certaines facs peuvent enseigner Merise mais c'est a eviter - UML fait la meme chose et plus). C'est utilise non seulement pour faire du design de base de donnees (qui ne sont, apres tout, que des gigantesques tables), mais aussi pour faire le design de tout ton systeme informatique (logiciel, hardware, etc!).

8 - Ne baisse jamais les bras si tu as une "vision" de ton objectif

La machine est un outil. Pour etre un bon programmeur il faut savoir en ton for interieur que tu peux lui faire faire ce que bon te semble [flashback the Ghost in the Shell et le hacking de cerveau... :-)]. Donc il y a toujours une solution pour n'importe quel bug et n'importe quel probleme! Attends-toi a debugger pas mal ton propre code, mais c'est un mal pour un bien: le plus tu debugges tes erreurs a la con, le plus tu les evites apres. :-) Cest ca qui est bien du compilateur parce qu'ils te dit ce qui ne va pas. Il faudra aussi t'habituer a afficher tes compteurs, etc. a l'ecran car parfois le bug est dans l'algo (donc ca compile, mais ca ne fait pas ce que tu veux). Mais, c'est en forgeant beaucoup qu'on devient bon forgeron. :-)

9 - La main pixelisee de la carte graphique est plus rapide que l'oeil humain

Il y a plein de petites "gruges" que tu peux utiliser pour optimiser la vitesse. Beaucoup te diront (et ils n'ont pas tort) qu'un bon algo economise du temps, mais ce n'est pas tout. Le truc est de voir quelles partie de ton codes bouffent le plus de resources. Par exemple, dans une demo il y a plein de trucs qui tournent autour d'un cercle, ce qui en general requiert beaucoup de calculs de sinus et cosinus. Mais, ces calculs sont tres lourds en temps de machine. Comment le contourner? Facile: tu n'as qu'a "pre-calculer" tout ca avant de lancer la demo (tu n'as pas besoin de beaucoup de valeurs en fait), tu stockes tout ca dans uen table que tu lis en temps reel (=tres rapide puisque c'est acceder un espace en memoire sans faire de calculs), et le spectateur ne verra que du feu. :-)

10 - URLs et autres sources d'inspiration

Bon sinon pour les bases de la programmation, perso j'ai plutot appris en cours en me referant a beaucoup de bouquins cites dans mon article plus haut. :-) En general j'ai remarque que j'apprenais plus si je recopias a la main le code d'un livre au lieu d'utiliser la source dans le CD qui vient avec... parce que ca t'oblige a comprendre ce qui se passe. :-) Toute source est bonne, mais commence petit et construis ton schmilblik a fur a mesure (exemple, d'abord affiche une fenetre, ensuite une fenetre avec une image, ensuite un bouton qui switche entre plein ecran et fenetre, ensuite un sprite, ensuite des inputs du clavier, ensuite des ennemis, etc...). Encore une fois tout depend de ce que tu veux apprendre, mais tu peux preparer une serie d'objectifs a atteindre, comme un escalier qui te mene la ou tu veux arriver...

12 - N'hesite pas a poser des questions

Aussi la pire erreur que tu peux faire c'est d'avoir peur de poser une question (ce qui est tres commun, surtout en cours!). Pas tout le monde va repondre tout le temps, ou sur le web tu auras beaucoup de "RTFM!!!", mais globalement tu pourras avancer en comprenant petit a petit. Meme si la question est ultra-conne - ca vaut le coup d'avoir l'air con si a la fin on comprend ce qui se passe. C'est mieux que d'avoir l'air intelligent alors que, dans notre tete, il y a un enorme point d'interrogation. (Socrate avait dit un truc du genre je crois...).

13 - etc.

Bon je pourrais encore m'etaler d'avantage, mais j'espere que ca te donne deja une idee. Si tu comprends les algos et les concepts, tu pourras utiliser n'importe quel langage pour arriver a tes fins. Bien sur tu ne seras pas le "dieu du C++" mais tu auras beaucoup plus de facilites pour convertir une idee en programme/jeu/demo concret, et t'adapter a des nouveaux langages si, par exemple, t'es dans un boulot et on te demande d'essayer une autre technologie. C'est fun mais c'est aussi un "avantage competitif". :-)

- Newsdee, le 15 Juin 2003.