AlexMog

LA COMMANDE DE LA VIE SUR LINUX: par exemple man ls

Shell Git de mon côté, et le client Git classique sur linux (oui, j'aime utiliser Git en lignes de commandes, and so what? En plus, ça me permet d'avoir un pseudo powershell sur windobe \o/)

Intéréssente comme mise à jour . Hâte de voir ce que ça va donner!

La SDL Bypasse OpenGL pour en faire de la 2D (OpenGL permet aussi de faire de la 3D), en utilisant la SDL en temps que fenetrage, tu peux donc faire de la 3D.

Hahaha, jerry, on trouve toujours meilleur que soit, et on a jamais finit d'apprendre jeune padawan! Bienvenue sur Melinyel! (par contre, je suis moi même choqué par le "codeur pro" surtout à 17 ans, j'ai moi même 19 ans, avec plus de 10 ans de prog, et même avec toute l'exp que j'ai, je ne me considère pas du tout comme un pro, loin de là! Je connais des barbus qui ne jurent que par le C et qui me poutrent en quelques minutes )

joli

Autant pour moi, je me suis mal exprimé. Par contre, ca ne change pas le problème de duplication des données.

Autant pour moi pour les sources windows, et merci pour l'info Pour le stackframes, sache que la stack est sauvegardée AVANT d'initialiser le stackframe d'une fonciton. (on le voit dans le code ASM des fonctions en C), voici un code ASM d'exemple: ;; exemple avec la fonction "hello world" x86 asm global main extern printf section .text main: push rbp ;; Ici, le generic push mov rbp, rsp ;; Suite du generic push (on le retrouvera dans toutes les fonctions en C (sans exceptions, il est ajouté automatiquement par le compilateur) mov rdi, FormatStr ;; 1er param de printf call printf ;; call de printf mov rsp, rbp ;; on remet l'ancienne stack en place pop rbp ;; on vire la sauvegarde de l'ancienne stack mov rax, 60 ;; on prépare l'appel au systcall "exit" xor rdi, rdi ;; on passe le paramètre 0 dans rdi (xor x, x revient à mettre 0 dans x (car un xor de 2 même valeurs donne 0) syscall ;; appel du systcall n°60 ret ;; section read only section .rodata FormatStr db 'Hello World !',0Ah,0 (c'est ce que j'appelle dans mon code le "generic push", on voit très bien que l'ancienne stack est sauvegardée dans la mémoire exécutive)

Les registres sont contenus dans la mémoire du processeur (sisi, vous savez, la mémoire cache ), on parle de registres en ASM uniquement. Ils ne sont pas accessibles en C, c'est la base des calculs du processeur. Je l'avais déjà expliqué plus tôt (voir mon cours sur les stacks), lorsque tu lance une fonction, celle-ci sauvegarde l'ancienne stack (et la récupère à la fin de la fonction), du coup, tu as un push sur la stack de l'ancienne stack, si tu y ajoute ce que tu as passé par copie, tu repush ce qui a déjà été push en stack. POur les structures, tout est dans mon cours. Alors non, pas du tout, et c'est là que linux est concret pour apprendre à programmer! Le principe de l'openSource de linux te permet de savoir beaucoup de choses sur les fonctions que tu utilises, mais là n'est pas la question. Pour recoder une fonction de la libC, il te faut uniquement les fonctions qu'à utilisée la libC pour être crée: les fonctions system. Une fois que tu les as, surtout, ne regarde pas les sources existantes! Ca ne sert à rien, autant essayer de réfléchir par toi même pour comprendre comment ça marche! Une fois que tu as tenté de recoder toi même, vas voir les sources, et pleure un bon coup, en voyant que printf, c'est assez lourd quand même . Code blocks ne t'aidera pas, car les libs ne sont pas open-source sur windows (en tout cas, les libC)

Bonjour à tous, Dans ce cours un peu spécial, nous allons voir ensemble les bonnes pratiques à prendre en C, nous allons aussi voir dans quels cas certaines choses sont plus optimisées que d'autres. Nous allons donc voir d'une manière générale la propreté du code, et l'optimisation de celui-ci en passant par des exemples d'erreures que tout le monde fait. I- Propreté du code. Pour un code lisible en C, il est impératif de bien construire son code. Les fichiers .h (headers) sont là pour les prototypes des fonctions, ainsi, le .c ne contiendra QUE le code des dites fonctions (et non pas des prototypes ou autres structures qui trainent dans des .c... BUARK!). DECOUPEZ VOTRE CODE! Plus votre code sera découpé, et mieu il sera, plus vous ferez en sorte d'avoir un certain nombre de fonctions (en évitant les fonctions "poubelles" quand même...), plus votre code sera lisible et propre! Prensez donc bien à découper votre code! Evtez les fonctions de 300 lignes! (ce qui rejoint le paragraphe précédent), effectivement, vous vous en sortez mieu en découpant le tout . Essayez de respecter la taille d'un terminal (hé oui, les programmeurs Linux programment souvent sur le terminal, il faut penser à eux!) qui est de 80 caractères. Ainsi, évitez de dépasser les 80 caractères par lignes de code . Les includes se font EN HAUT du code, je ne veux plus jamais voir des includes en plein milieu d'un code source... BRRRRR! Vous pouvez, en plus, respecter un certain format d'include, certains trient par ordre alphabétique, d'autres par longueur, le but étant de mettre tout de même les includes System AVANT les includes perso. ex: // Ca c'est bon #include <stdio.h> #include "mon_include.h" // CA C'EST BOF! #include "mon_include.h" #include <stdio.h> Evitez les includes inutiles! Cela ralentiera votre compilation si vous gardez des includes qui n'ont rien à faire là! Pensez à sauter des lignes, éviter le multi-exécution sur une ligne... c'est pas très propre. Bref, rendez votre code LISIBLE! Un code source, c'est comme un livre, si tout est en bordel, on a pas envie de le lire . II- Optimisations et bonnes pratiques! Passons à la partie la plus intéressente! L'optimisation et les bonnes pratiques. D'une manière générale les deux sont proches. Au niveau des optimisations, nous allons d'abord commencer par un cas très spécial: Doit-on passer par copie ou pas? (ceci ne s'applique pas aux typpages de base, mais plutôt aux tableaux et aux structures). La réponse est simple: TOUT DEPENDS DE VOTRE CODE! Si vous souhaitez utiliser la variable que vous passez dans une fonction de manière locale à ladite fonction, passez la par copie. Dans le cas contraire, si vous voulez modifier une structure ou les cases d'un tableau par exemple, NE LA PASSEZ PAS PAR COPIE! Laissez votre stack tranquile non de dieu! Pour bien vous faire différencier ce qui est une copie et ce qui ne l'est pas, vouci des exemples concrets. // Ceci est une copie (buark) void mafonction(int tab[10]); // Ceci n'est pas une copie void mafonction(int *tab); void mafonction(int tab[]); // Ceci est une copie void mafonction(struct mastruct s); //Ceci n'est pas une copie void mafonction(struct mastruct *s); Nous avons aussi le cas de l'allocation, quand faut-il allouer de la mémoire? Déjà, il faut savoir que l'allocation dynamique est la chose la plus LOURDE dans le monde de la programmation. Il est donc conseillé d'allouer tout l'espace naisséssaire au chargement de son programme, pour éviter d'allouer en plein milieu. Si les allocations sont rares, on peut tout de même les utiliser de manière dynamique. Mais il ne faut surtout pas en abuser! (c'est pour cela qu'un tableau à une dimension (au niveau de l'alloc) sera moins lourd qu'un tableau à double dimensions). Une autre pratique qui est plutôt bonne à connaitre pour l'optimisation: les calculs à base d'INT. Pourquoi utiliser le typpage int plutôt que float? Il faut savoir que les int sont stockés sur un seul registre, alors qu'un float (chiffre à virgule) est stocké sur 4 registres (merci l'ASM de nous le démontrer), il est donc conseillé d'utiliser des int plutôt que des float pour optimiser les calculs. N'oubliez pas que le calcul sur 4 registres sera TOUJOURS plus long que le calcul sur 1 registre (4x plus long), et cela, peut importe la valeur stockée dans les registres. Enfin, la meilleure pratique pour bien optimiser son programme, c'est savoir de quoi est composé le dit programme! Je m'explique, utiliser des fonctions préfaites par la LibC, c'est bien, mais quand on ne sait pas comment elles fonctionnent, c'est MAL! En effet, vous êtes plusieurs à ne pas savoir que dans certains cas, printf n'est pas du tout optimisé (en effet, printf passe par 3 boucles ET une bufferisation des données AVANT affichage, alors qu'un simple puts ou write aurait fait l'affaire!), je vous conseille donc de vous renseigner sur les fonctions que vous utilisez, ou encore mieu! RECODEZ LES! Vous apprendrez beaucoup plus ainsi que de n'importe qu'elle autre manière! Je vous invites à lire mes cours dans la section C, qui utilisent le principe de l'utilisation de Fonctions System au lieu de passer par des fonctions de la LibC, pour vous apprendre à bien comprendre la différence entre les deux, et avoir de bonnes habitudes (qui sait, vous comprendrez peut être comment ça marche ) Si vous désirez d'autres informations, n'hésitez pas à laisser un commentaire ci-dessous! A très bientôt pour un prochain cours! AlexMog.

Théoriquement, c'est possible de les recoder, mais en ASM uniquement.

Le danger, c'est qu'elles sont stockées exactement comme des globals: DANS le binaire. Ce qui allourdit le binaire (vraiment beaucoup) et qui est... Dégueulasse...

PAs besoin de se prendre la tête. Tu vas dans les headers (sous linux, c'est pour ça que linux est plus adapté) system, et tu regarde simplement la liste des fonctions system (les fonctions system sont déjà codées en ASM, tu ne peux pas aller plus bas niveau, c'est donc la "base" de la programmation en C, tu peux trouver une liste des fonctions system sur Google aussi!) Une fois que tu as les fonctions system, tout le reste c'est de la logique! Interdit toi les fonctions de la libC, et tu verra, tu codera un Printf rapidement, et tu comprendra comment il marche (ça marche avec absolument toutes les fonctions de la libC, je t'invites à lires mes cours, qui n'utilisent QUE des fonctions system.) Enjoy!

J'ai jeté un petit coup d'oeil à ton code, les static, faut éviter! Il faut en utiliser réellement en cas de besoin, tu peux TOUJOURS les éviter, c'est assez dangeureux, car, au même titre qu'une globale, elle est stockée directement dans l'exécutable (ce qui est... sale...) autre chose: Pas de protection contre la double inclusion dans les .h... C'est MAL!

Je vais te gronder, mais c'est pas grave , c'est comme ça qu'on apprends

Je compte faire un tutoriel là dessus dès que j'aurai le temps (par exemple, savoir quand il faut passer une structure par copie, etc..), donc je te laisse attendre un peu, le temps que je monte le cours .

Si tu regardes bien, le stade de dev commence à partir de la alpha 1.2.6. A la base, jusqu'à la 1.3, c'est Notch qui développait seul, mais le problème, c'est qu'il code salement -true story, minecraft consommait 3/4 Go de ram avant- puis jebs est arrivé, et à TOUT remanié.

Il faut déjà utiliser un logiciel de versionning (ici, j'utilises GIT), puis appliquer Gource sur le dossier du projet

Salut à tous, Je vais vous présenter ma petite galerie de créations Gource. Avant tout, qu'est-ce que Gource? Gource permet de créer une manière artistique de voir les modifications apportées sur un projet via des gestionnaires de versionning (git, svn, etc...), on voir donc, au fil du temps les fichiers créés, et les améliorations apportées à un projet. Je vais donc faire une petite galerie Gource de mes projets, si vous souhaitez voir un peu comment se passe la création d'un programme/jeu . Melichat de la version 001 à la version 092: KillDaMinions - Développement complet: Je vous en posterais d'autres dès que possible Enjoy! Et si d'autres dév s'y mettent, je serais ravis de voir ça Cordialement, AlexMog.

BEAUCOUP de monde me demande en combien de temps j'ai développé Melichat, je vous propose donc de découvrir, de manière artistique, comment a été créé le serveur actuel de Melichat. Grâce à cette vidéo, vous allez voir du commencement à la version 092 de melichat! Enjoy !

C'était une faille coté client, qui a été corrigée

Salut, Pour avoir testé la SDL 1.2, j'ai trouvé énormément d'avantages au niveau de la SFML 1.6 (la SFML 1.6 étant une ancienne version obsolète), elle est pensée objet, et donc, le C modulaire est bien foutu (c'est du binding du C++) à la différence de la SDL 1.2 (et 2 d'après ce que j'ai lu jusqu'à présent). J'ai toujours préféré les langages qui rapprochent de l'objet, donc le C modulaire est plus appréciable, ce qu'offrait la SFML. Ensuite, niveau perfs, la SFML n'est pas à envier, et a beaucoup d'avantages => PAs très lourde, et fournit beaucoup d'outils. Ensuite, oui, la SFML est développée par un seul homme, qui est FRANCAIS! (ce qui donne encore plus envie), elle est d'ailleurs OpenSource, ce qui m'a encore plus attiré vers la SFML. La SFML a un très bel avenir, car elle commence à être utilisée par les grosses boites (on voit l'exemple de Ubisoft qui a modifié une version de la SFML pour un mini-jeu). Bref, elle a un bel avenir, je ne peux malheureusement rien dire sur la SDL 2, je ne l'ai pas testée. Cordialement, AlexMog.

Réparé, merci pour l'info. Effectivement, j'ai tout codé directement sur Meli, donc j'ai pas pu tester ^^'

Une librairie graphique très intéréssente à utiliser et complète. t'as toutes les infos ici: http://www.sfml-dev.org/index-fr.php

Bonjour à tous, Je vais vous apprendre aujourd'hui à installer la SFML2.1. Le problème actuel réside dans le fait que la SFML2.1 n'est pas encore sur les dépots officiels de Debian, nous sommes donc obligés de télécharger les sources et tout compiler à la main (et se retrouver souvent avec des dépendances manquantes). Mais qu'à cela ne tienne! J'ai un dépo perso que je vous met à disposition, qui contient plusieurs de mes projets (dont ma lib réseau) ainsi que la libSFML! Voici comment installer le dépôt, et installer la SFML2.1 (lancez la commande): Si vous avez des problèmes pour rajouter la ligne à /etc/apt/sources.list rajoutez ceci dedans à la main (tout en bas du fichier): Puis lancez les commandes suivantes: Ceci va installer la SFML2 et ses dépendances. Enjoy and dev well! Cordialement, Alexmog.