* Sax oblige a écrire plein de callbacks. Ca fait tout ce dont on peut avoir besoin, mais c'est assez lourd à coder.
* DOM chargeant tout en mémoire, ce n'est pas adapté pour les gros fichiers.
;

Introduction

Le XML c'est génial, le XML c'est beau, le XML vous fait le cacao le matin.

Pour charger un fichier XML, il y a traditionnellement deux API : Sax et DOM

• Sax oblige a écrire plein de callbacks. Ca fait tout ce dont on peut avoir besoin, mais c'est assez lourd à coder.
• DOM chargeant tout en mémoire, ce n'est pas adapté pour les gros fichiers.

Stax

L'API de type Stax est un juste milieu entre des deux approches. L'idée, c'est qu'au lieu de laisser le parseur tout gérer, on va lui demander un élément, l'analyser nous-même, puis demander l'élément suivant.

La libxml2, du projet Gnome, fournit une API de ce type. Elle est plutôt bien documentée, mais les exemples, mêmes s'ils sont fonctionnels, ne sont pas très utiles tels quels : la plupart accèdent à un élément connu d'avance et listent ses propriétés. Généralement, quand on a un fichier XML tellement gros qu'on ne peut pas utiliser DOM, la problématique est plutôt : découvrir à la volée ce qu'on a dans le fichier.

Fichier d'exemple

Pour ce tutoriel, j'utiliserai des fichiers de dump OpenStreetMap, qui peuvent atteindre plusieurs centaines de Go. Un bon test pour les fuites mémoires...

En simplifié , ça ressemble à ça (ici sur un bout de granite près de Lannion) :

<?xml  version="1.0" encoding="UTF-8" ?>
<osm version="0.6"  generator="CGImap 0.0.2">
    <bounds minlat="48.7640630"  minlon="-3.5936820" maxlat="48.7670190" maxlon="-3.5882580"  />
    <node id="28204783"  lat="48.7661740" lon="-3.5946960">
        <tag k="created_by"  v="almien_coastlines" />
    </node>
    ... encore beaucoup de texte

Donc, une racine "osm" avec un noeud "bounds" et une liste de noeuds "node", tous avec des attributs.

Initialisation

L'initialisation est très simple, et bien expliquée dans les tutoriaux officiels :

xmlTextReaderPtr reader = xmlReaderForFile("machin.xml", NULL, 0);
if (reader == NULL) return;
// 1 if the node was read successfully, 0 if there is no more nodes to read, or -1 in case of error :
if (xmlTextReaderRead(reader) == 0) return;
readRoot(policy); // C'est ici qu'on va lire la racine du fichier, et tout les enfants
xmlFreeTextReader(reader);

Lecture

Voyons voir cette fonction readRoot :

Tout d'abord, un petit test pour être sûr que l'on a pas fait de bêtise :

if (xmlTextReaderDepth(reader) != 0) return error("Le noeud racine devrait être OSM");

Ensuite, on demande au parser le nom de l'élément suivant. Il va donc lire juste ce qu'il faut du fichier pour savoir ça, et s'arrêter :

xmlChar *name;
name = xmlTextReaderName(reader);

On vérifie alors qu'on a bien un noeud "osm" comme racine:

if (name == NULL) return error("pas de noeud racine");
if (xmlStrcmp(name, (const xmlChar *) "osm")) return error("Ceci n'est pas un fichier OpenStreetMap");

Maintenant qu'on est sûrs qu'on est dans l'élément qu'on veut, on n'a plus besoin de name, donc on le libère :

xmlFree(name);

Ensuite, on va lire tous les attributs, par exemple pour vérifier qu'on est bien en OSM 0.6 :

while(xmlTextReaderMoveToNextAttribute(reader)){
    xmlChar *name_attrib, *value_attrib;
    name_attrib = xmlTextReaderName(reader);
    value_attrib = xmlTextReaderValue(reader);
    if (!xmlStrcmp(name_attrib, (const xmlChar *) "version") && xmlStrcmp(value_attrib, (const xmlChar *) "0.6")){
        std::cout << "Attention, la version du fichier n'est pas 0.6" << std::endl;
    }
    xmlFree(name_attrib);
    xmlFree(value_attrib);
}

Remarquez que les attributs ne sont absolument pas ordonnés, ni accessibles tous d'un coup. Si c'est le comportement que vous souhaitez, utilisez une map (ou map )
On veut maintenant lire les enfants : on demande le chunk suivant, on regarde son type, et on avise. Et on répète jusqu'à ce que le fichier soit vide, càd que xmlTextReaderRead retourne 0 (fin) ou -1 (erreur).

L'astuce, c'est que dans le "on avise", on va également pouvoir appeler xmlTextReaderRead, et lire ainsi récursivement tous les enfants :

int ret = xmlTextReaderRead(reader);
while (ret == 1) {
    xmlChar * name = xmlTextReaderName(reader);
    if (!xmlStrcmp(name, (const xmlChar *) "bounds")){ ret = readBounds();}
    else if (!xmlStrcmp(name, (const xmlChar *) "node"  )){ ret = readNode();    }
    else if (!xmlStrcmp(name, (const xmlChar *) "way"   )){ ret = readWay();}
    else                                                  { ret = xmlTextReaderRead(reader);} // Ne devrait pas arriver, mais peut-être que le fichier est mal formé ?
    xmlFree(name);
}

Et voilà ! readBounds n'a pas de surprises, il n'y a que des attributs, mais voyons readNode pour l'exemple :

if (xmlTextReaderDepth(reader) != 1) return error("un Node doit être au niveau 1");
while(xmlTextReaderMoveToNextAttribute(reader)){
    // Faites ce que vous voulez avec les attributs
}
int ret = xmlTextReaderRead(reader);
while (ret == 1) {
 
    // un noeud frère ou parent arrive : on redonne le contrôle au parent pour qu'il le gère.
    // Si c'est de nouveau un noeud, readRoot rappellera tout naturellement readNode.
	if (xmlTextReaderDepth(reader) <= 1){
		return 1; // 1 = lire la suite (cf readRoot)
	}else{ // child node
	xmlChar * name = xmlTextReaderName(reader);
        // faire quelque chose en fonction de name. Ici, on lit en boucle en ignorant les tags
        ret = xmlTextReaderRead(reader);
        xmlFree(name);
    }
}
return 0; // Ne devrait pas arriver

Lecture de très gros fichiers

Quand on lit des fichiers de 200Go, il est souvent utile de prévenir l'utilisateur de là où on en est, histoire d'éviter le ctrl-c furieux. On sort alors un peu d'une utilisation "simple" de la libxml2, mais c'est possible.

Tout d'abord, on abandonne xmlReaderForFile au profit de xmlNewTextReader, qui prend en paramètre un xmlParserInputBufferPtr. Cet objet implémentera les callbacks de lecture de fichier (i.e. fopen, fread, etc), tout comme xmlReaderForFile le fait en interne, à la différence près qu'on va retenir là où on en est dans le fichier.

Tout d'abord, on veut trouver la taille du fichier, en octets :

FILE * file = fopen(path,"r");
if (!m_file) return -1;
 _fseeki64(m_file,0, SEEK_END);
 __int64 size = _ftelli64(m_file); // la taille
 _fseeki64(m_file,0, SEEK_SET);

Remarquez que l'on n'utilise pas fseek, qui sont limités à des fichiers de 3Go (adressable en 32 bits). Les streams C++ ont le même problème sur les OS 32 bits, d'où l'utilisation de ces fonction assez incongrues en C++.

Maintenant, créons notre parseur :

xmlParserInputBufferPtr input = xmlParserInputBufferCreateIO(
    xmlInputReadCallback_Function,
    xmlInputCloseCallback_Function,
    this, // Ou n'importe quel objet, ou même NULL si vous mettez vos données en global
    XML_CHAR_ENCODING_NONE
 );
reader = xmlNewTextReader(input, "foobar file"); // Le second paramètre est obligatoire et inutile

Nous avons donc besoin de deux fonctions : xmlInputReadCallback_Function et xmlInputCloseCallback_Function. La seconde est assez évidente (fclose), intéressons-nous à la première :

int xmlInputReadCallback_Function (void * c, char * buffer, int length ) {
    // length est la taille du buffer demandé.
    // Sauf si vous avez recompilé la lib avec des options particulières, ce sera 4096, soit 4Ko
    UpdateProgress(length);
    // Lit 4096 octets du fichier dans le buffer
    return (int)fread(buffer,1,length,file);
}

Voilà, le callback est fini. Il ne vous reste plus qu'à implémenter UpdateProgress à votre convenance. Par exemple, pour une application en ligne de commande :

pos+=length; // On retient la position actuelle
if (m_size && (100*(m_pos-length)/m_size) != 100*m_pos/m_size) // Si la position a changé de plus de 1%
 std::cout << (int(100*m_pos/m_size)) << std::endl; // on affiche

ce qui fera un compteur de 1 à 100. Avec Qt, un signal en Qt::QueuedConnection (pour éviter de bloquer l'UI) fera également très bien l'affaire.

Conclusion

Nous avons donc vu comment lire un très gros fichier XML avec l'API Stax de la libxml2. Maintenant, il ne vous reste plus qu'à encapsuler tout ça, vu que pour des raisons de simplicité, j'ai fait comme si toutes les variables étaient globales.

Donc pour résumer :

• DOM si vous pouvez
• Sax si vous êtes obligés (pas d'autre API sur votre plate-forme, ...)
• Stax sinon !

C'était mon tout premier tuto Une pièce d'histoire...

Welcome pour mon premier tuto

Nous allons apprendre à faire un truc trop cool, de la POO en assembleur.
Mais bon on va y aller doucement, on va commencer par interfacer asm et C.

Pour commencer, quel est l'intérêt ? Tout simplement d'avoir accès à toutes les possibilités de l'assembleur tout en gardant un contrôle total sur le code généré (puisque justement c'est nous qui le générons ^^ ).
Evidement on pourrait simplement mettre asm{ /* code */ } mais le compilo rajoute ses propres trucs, et si on a une application très spéciale ça peut être embêtant ( je pense tout particulièrement à ScalP pour ceux qui connaissent, où j'ai été obligé de faire ça ): on n'a pas de contrôle sur les registres utilisés ainsi que sur l'utilisation de la pile, à laquelle on peut vouloir accéder.
En outre ce n'est absolument pas portable, chaque compilo a sa propre syntaxe.
De toute façon pour les indécis j'ai un argument-choc : ça fait méga g33k!
convaincu ? ^^

Alors allons-y...

Interfacer assembleur et C

Appeler de l'assembleur en C

Pour ceux qui ne connaissent absolument rien à l'assembleur, un chti tuto est disponible [url="http://www.coder-studio.com/?page=tutoriaux_aff&code=asm_1"]ici[/url], merci Funto !

Disons qu'on a ce programme :

// main.cint asm_carre (int);
int main( int nagrs, char ** vargs){
 int a = 4;
 int b = asm_carre(a);
 printf("D'après notre fonction assembleur, le carré de %d vaut %d\n",a,b);
 return 0;
}

avec int asm_carre (int) une fonction que l'on va implémenter en assembleur.
On écrit le prototype dans le .c pour que le compilateur connaisse la fonction.
Bien évidemment ça ne compilera pas dans l'état, personne ne connaît où se trouve l'implémentation de asm_carre.
Mais où mettre cette implémentation ? simple, dans un .asm... gogogo !

; asm_carre.asm
[BITS 32]
segment .data ; données initialisées: rien pour l'instant.
segment .bss  ; données non initialisées, toujours rien.
segment .text ; ah ! on entre dans le CS ( Code Segment )
 global _asm_carre ; on va exporter ce symbole
_asm_carre:
 enter 0,0         ; on n'utilise aucune variable, uniquement des registes.
 push ebx          ; La valeur de ebx ne DOIT PAS être modifiée par la fonction !! alors on le met temporairement sur la pile ( même si dans ce cas précis c'est inutile )
 mov eax,[ebp+8]   ; le paramètre de la fonction ce trouve à cet endroit.
 mul eax           ; eax = a*a
 pop ebx           ; on restaure ebx
 leave             ;
 ret               ; retour à la fonction appelante

héé partez pas
Pour les quatre premières lignes, si vous ne comprenez pas refaites un petit tour sur le tuto de Funto.
bon.
pourquoi global? pour dire à NASM que cette fonction pourra être appelée d'un programme externe.
pourquoi _asm_carre et non pas asm_carre ? C'est une convention d'écriture. Chaque fois que vous voudrez créer une fonction asm devant être appelée à partir du C, il faudra préfixer le label par _

ensuite place à l'implémentation.
Attention, rappelez vous que la pile de processeur commence à DROITE et s'aggrandit vers la gauche, donc quand on pushe une variable, elle se met le plus à gauche possible. Du coup ce qui se trouve en ebp+4 a été mis sur la pile AVANT ce qui se trouve en ebp+0

enter 0,0 : ne sert pas à grand chose ici.

push ebx : ici cela n'est pas réellement utile non plus puisque ebx, on n'y touche pas; mais c'est une question de bonnes habitudes car il est interdit pour une fonction de modifier ebx ( quand on l'interface avec du C/C++ tout du moins, en asm pur vous faites ce que vous voulez )
C'est embêtant ça ! déjà que des registes on n'en a pas beaucoup... alors du coup on le pushe, et on le popera juste avant de redonner la main au C.
à vrai dire.. il n'y a pas que ebx, mais aussi esi,edi,ebp,cs,ds,ss et es ... au pire : pusha / popa.
]

----------------------------------------------------------------
| adresse ||| ebp - 4  | ebp + 0  |    ebp + 4     |  ebp + 8  |
----------------------------------------------------------------
| contenu |||   ???    |    ebp   | adresse retour | parametre |
----------------------------------------------------------------

mov eax,[ebp+8] : strico sensu, met ce qui se trouve en ebp+8 ( sur la pile ) dans eax. Mais qu'est-ce qui se trouve donc en ebx+8 ? ohhh, notre paramètre

mul eax,eax : on multiplie eax par lui même ...

pop ebx: voilà, comme ça le standard est respecté et on risque pas de se retrouver avec erreurs incompréhensibles.

leave: symétrique de enter

ret : pope l'adresse de la fonction appelante et y va: ici, on était dans le main, ligne 2...

et voilà nous revoilà dans notre programme C avec le carré du paramètre dans eax. cool, ça sert à quoi? hé bien justement, la valeur de retour d'une fonction DOIT être dans eax, c'est la règle. Et du coup, tout est bon, b=a^2.

En fait on pouvait faire plus simple, c'est là tout l'avantage de l'assembleur :

_asm_carre:
 mov eax,[esp+4]
 mul eax
 ret

fini ! La rule of thumb, c'est 1 : vous ne modifiez pas les registres cités plus haut et 2 : valeur de retour dans eax.
[nota : eax c'est pour les DWORDS. Pour un WORD c'est ax, pour un QWORD, edx:eax]
remarquez que je n'ai pas utilisé ebp (base pointer) mais esp ( stack pointer ) car il n'y a pas la commande enter, dont l'un des rôle est justement de faire mov ebp,esp.

Bon , compilons ! OK c'est bon ça marche... Argheul nan, la compilation se fait sans ennuis mais erreur au linkage : l'éditeur de liens ne sait pas où trouver l'implémentation de asm_carre. Et pour cause ! il n'a pas été assemblé :niii:
Qu'à cela ne tienne :

C:\>nasm.exe -o asmlib.o -f coff asm_carre.asm

( si vous n'êtes pas sous windows utilisez -f elf )
Voilà vous avez un merveilleux .o ! Il n'y a plus qu'à demander au compilo de linker avec , et magie !! ça plante
[NOTAs :

• on peut utiliser aussi, nasm -f win32 asm_carre.asm , ca donnera asm_carre.obj, à linker de même manière.
• Pour éviter de retourner dans la console à chaque modif on peut aussi faire ça automatiquement : dans VC6, Project->Settings-> onglet pre-link step-> nouveau-> entrez cette ligne...

]

( bon en fait non ça plante pas mais c'est parce que vous avez de la chance )
La raison est simple, la convention d'appel utilisée par le compilo C++ est le _stdcall ( params empilés de gauche à droite, dépilés dans la fonction elle même ) et il y a de fortes chances pour que vous ayez écrit votre fonction assembleur en _cdecl ( params empilés de droite à gauche, dépilés par le programme appelant ). Aurement dit, gros plantage assuré s'il n'y a pas la même convention des deux côtés (heureusement ici c'est du C, pas du C++, donc pas de plantage en fait) .
pour spécifer la convention :

• sous VC++ : _cdecl int fonction ( int ); // respectivement _stdcall
• sous GCC : int fonction ( int ) __attribute__((cdecl)); // respectivement stdcall

Yeah ! Là ça marche vraiment, et on sait pourquoi

Appeler de l'asm, qui appelle du C

Bon, on ne va pas s'arrêter en si bon chemin ... maintenant qu'on sait écrire des fonctions hyper puissantes et polyvalentes en assembleur ( *hum* ), on aura sûrement besoin, à un moment ou à un autre, d'appeller une fonction qui elle est implémentée dans le prog C, ou même dans les librairies standard ... genre strcmp !

Pour ça c'est très simple, il suffit de déclarer le nom de la fonction en extern au début du segment .text et le linker s'occupera de tout.

Dans le genre "Programme qui sert à rien" ça donne ça:

// main.c
int _cdecl asm_carre (int);
int main( int nagrs, char ** vargs){
 int a = 4;
 int b = asm_carre(a);
 printf("D'après notre fonction assembleur, le carré de %d vaut %d\n",a,b);
 return 0;
}
int _cdecl carre(int a){return a*a;}

puis:

; asm_carre.asm
[BITS 32]
segment .text
 global _asm_c_carre:
 extern _carre ;remarquez qu'ici aussi on met un _
_asm_c_carre:
 mov eax,[esp+4]   ; on prend le param sur la pile
 push eax      ; on le re-pushe au sommet de la pile
 call _carre      ; on appelle la fonction
 add esp,4         ; on dépile
 ret               ; on retourne au C

Héé oui vous l'aurez compris, ce code atteint le sommum de l'inutilité en appellant la fonction asm_carre qui se contente d'appeler carre(), qui lui est implémenté en C ^^
Attention cependant, cela ne marche pas avec le format COFF, le win32 est impératif ( et souvenez vous que du coup ça donne pas en .o mais un .obj)

Interfacer assembleur et C++

- Here comes the bidouille -

Bien, toutes les bases sont posées, ce que vous ferez de cela dépendra de vos connaissances en assembleur.
Mais maintenant nous sommes en 2006, ya un truc qui est pas mal : le C++.
ça serait bien qu'on puisse interfacer le C++ et l'assembleur de la même manière qu'avec le C... non?

Malheureusement la convention qui nous dit de rajouter un petit _ , c'est une convention C ! et non C++ ...
c'est là que les embrouilles commencent, parce que les éditeurs de compilateurs s'en sont donné à coeur joie pour nous peaufiner des tonnes de conventions aussi différentes et incompréhensibles les unes que les autres...
ça s'appelle le name mangling ( décoration de nom ) et c'est pas du tout, mais alors pas du tout standardisé.
Heureusement, le linker est votre ami !
Ainsi, si vous renommez le main.c précédent en main.cpp, la compilation encore une fois se déroulera sans souci, mais le linker va vous sortir une erreur du genre :

tuto.obj : error LNK2001: unresolved external symbol "int __cdecl asm_carre(int)" (?asm_carre@@YAHH@Z)

Oh magie , un joli nom de label tout bizarroïde apparaît : ?asm_carre@@YAHH@Z
Il suffit d'un petit copier-coller de ce nom pour remplacer tous les _asm_carre par ?asm_carre@@YAHH@Z dans le listing assembleur.
On réassemble, on recompile, ça marche ! *joie*

Pour la compatibilité entre les différents compilateurs, on peut s'amuser à regarder toutes les erreurs de linkage créées par tous ces compilos, ajouter tous ces noms dans la liste des labels extern, et remplacer chaqun de ces labels par la liste des labels demandés par l'ensemble des compilos.....

Assembleur Orienté Objet ?

Oui c'est possible
Tout du moins à certaines conditions .....
Admettons que nous ayons une classe CMaClasse avec une fonction membre void Calcule(void).
hé bien jusque là c'est très simple : c'est exactement la même chose qu'avant. On regarde l'erreur du linker, on copie-colle le nom de la fonction.
Ca marche ... si et seulement si ladite classe est un POD ou au mieux un agrégat. Donc : pas de virtuel ! ni fonction ni membre ni quoi que ce soit de virtuel. On a le droit à l'héritage si ça reste un agrégat, mais bon ça devient plus compliqué après et à priori ça dépend du compilo utilisé.
( théoriquement, même avec du virtuel c'est possible mais n'y songez même pas ^^)

Bon , maintenant, admettons que l'on veuille prendre des paramètres. le prototype devient:

void CMaCLasse::Calcule(int a);

sauf que ...
sauf que c'est pas si simple, ce prototye c'est celui que vous écrivez, pas celui qui est utilisé.
le compilo, lui, il comprend ça:

void CMaClasse::Calcule( CMaClasse* this, int a);

c'est d'ailleurs pour ça que vous avez accès aux membres quand vous faites Instance->fonction();, ça tombe pas du ciel ...

Une fois dans la partie asm, voilà donc l'état de la pile:

----------------------------------------------------------------------------
| adresse ||| ebp - 4  | ebp + 0  |    ebp + 4     |  ebp + 8  | ebp + 12  |
----------------------------------------------------------------------------
| contenu |||   ???    |    ebp   | adresse retour |    this   | parametre |
----------------------------------------------------------------------------

'a' n'est donc plus en ebp+8 mais en ebp+12 ! à part ça rien ne change.

bon , maintenant que j'ai accès aux paramètres, je veux une valeur de retour: pareil qu'en C ! dans eax ...

[NOTA : dans la source d'exemple , j'accède à this avec mov ecx,[esp+4], mais c'est parce que je n'utilise pas enter et leave.

et dernier point fun : accéder aux membres
Le truc sympa c'est qu'on a this...
ce qu'il faudrait c'est donc ça : (ebp+8)->_membre, c'est à dire, en simili-nasm: [ebp+8]._membre
mais comment avoir l'adresse de _membre ? simple, pour un POD, le c++ demande que les membres soient stockés en mémoire de façon contigüe (cela est rarement respecté, voir plus bas) et dans l'ordre de la déclaration.
exemple:

class CMaClasse{
public:
 int a;
private:
 char c;
protected:
 float f;
};
CMaClasse inst;

dans ce cas, la mémoire sera :

0         4   5         9
-------------------------
| * * * * | * | * * * * |
|    a    | c |    f    |
-------------------------

( un * correspond un octet, le 4 signifie qu'on se situe à l'adresse &inst +4 )
( On voit d'ailleurs qu'il est presque toujours préférable de classer ses membres par taille décroissante, ça optimise les accès mémoire)

NOTA:
la plupart des compilos alignent automatiquement sur 4 octets (c'est plus rapide à l'exec), ce qui donne une organisation de la mémoire comme ça:

0         4        8         12
------------------------------
| * * * * | *      | * * * * |
|    a    | c      |    f    |
------------------------------

on peu configurer ça soi même l'alignement mémoire avec la directive pragma.
Pour comprimer au maximum la structure sous VC++ :

#pragma pack(push)
#pragma pack(1)
struct lkjlkj{...};
#pragma pack(pop)

et sous gcc:

struct ljhlkjh{
...
}__attribute__((packed)); // (oui c'est compliqué et alors ? :p)

/NOTA

nous disions donc que nous avions this en ebp+8 et qu'on voulait les membres... admettons que je veuille mettre f dans ebx. je dois alors faire:

mov ecx, [ebp+8] ;ecx=this;
mov eax, [ecx+5] ;eax=*(this+5); on met dans eax les 4 octets( 4 car c'est eaXX) situés à l'adresse this+5

(on peut optimiser avec lea , mais passons)
à partir de là on peut accéder au membres, une bonne idée est d'utiliser les macros de nasm pour y accéder plus aisément en donnant des noms compréhensibles a [ecx+5] ...)

voili voilou !!!
Comment ça ya plus personne avec moi :p

dernière chose: Magie de l'assembleur on peut même appeller des fonctions membres...mais fait connaître le label, pour ça il suffit de faire un appel de ladite fonction quelque part dans le c++ tout en commentant l'implémentation. Le linker va râler, et par là même donner le label qu'il cherche.
Ne pas oublier de pusher this! ...
Maintenant, petit truc sympa et bien utile: quand votre routine asm plante... mettez vous en mode débug dans VC++, relancez...vous verrez s'afficher le desassembly MASM de votre code NASM, avec la ligne à laquelle ça a planté...faites clic droit sur la barre des menus, cliquez sur registres: voilà, vous contrôlez votre machine B-) :p

Bon ben voilà, je verrai ce qu'il y a à ajouter à cela, please feel free de faire des commentaires dans le forum
N'oubliez pas d'aller voir les exemples.

Un zip est disponible [url="http://coder-studio.com/tutoriaux/asm/asm_4.zip"]ici[/url], et la discussion se poursuit [url="http://www.coder-studio.com/forum2/viewtopic.php?id=904"]là[/url] !

Introduction

Ce tutorial s'inscrit dans la lignée du tutorial sur les pbuffers, disponible [url="http://www.coder-studio.com/"]ici[/url] (NDLR : que je n'ai pas reporté tellement c'est vieux).
Le but est toujours le même : permettre d'enregistrer une scène sur une texture rapidement, afin de pouvoir réaliser moult joulis gfx
Nous avions vu que si les pbuffers étaient performants, ils n'existaient que sous Linux. Une extension plus récente a depuis fait apparition, ce sont les framebuffer objets. L'API pour y accéder a été normalisée par l'ARB mi-2004. C'est une extension complexe, la spec fait un demi-Mo de texte brut. Mais n'ayez pas peur, ça va bien se passer

Une caractéristique agréable du fbo est qu'elle permet, si toutefois la carte graphique le supporte, de dessiner sur des NPOTS : Non Power Of Two textures. Autrement dit, si votre écran fait 800*600, vous pouvez sans problème aucun avoir une texture de 800*600, dessiner dessus, puis l'utiliser comme une texture normale, au lieu de devoir utiliser une 1024x1024 et d'en perdre une bonne partie.

Nous allons donc voir comment utiliser ces textures rectangulaires, puis comment utiliser les fbos.

Les textures rectangulaires

Il s'agit ni plus ni moins d'une texture normale, très banale. La seule différence avec GL_TEXTURE_2D est son nom : GL_TEXTURE_RECTANGLE_ARB.
Sans plus attendre, voiçi un exemple complet de création d'une texture vide.

	glEnable(GL_TEXTURE_RECTANGLE_ARB);
	int taille_max;
	glGetIntegerv(GL_MAX_RECTANGLE_TEXTURE_SIZE_ARB,&taille_max);
	std::cout << " Taille max de texture supportée : " << taille_max << std::endl;
	GLuint rect_tex;
	glGenTextures(1,&amp;rect_tex);
	glBindTexture(GL_TEXTURE_RECTANGLE_ARB,rect_tex); // Exactement comme pour les tex2D
	glTexImage2D(GL_TEXTURE_RECTANGLE_ARB, 0, GL_RGB8, 800, 600, 0, GL_RGB, GL_INT, NULL);
	glTexParameteri(GL_TEXTURE_RECTANGLE_ARB, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
	glTexParameteri(GL_TEXTURE_RECTANGLE_ARB, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
	glTexParameteri(GL_TEXTURE_RECTANGLE_ARB,GL_TEXTURE_WRAP_S,GL_CLAMP_TO_EDGE);
	glTexParameteri(GL_TEXTURE_RECTANGLE_ARB,GL_TEXTURE_WRAP_T,GL_CLAMP_TO_EDGE);

Avant de continuer, quelques remarques nécessaires sur les NPOTS.
Il est impossible de créer des mipmaps. Ainsi, il ne faut jamais appeller glTexParameteri(GL_TEXTURE_RECTANGLE_ARB, GL_TEXTURE_MAG_FILTER, GL_LINEAR_MIPMAP_NEAREST); ou assimilé.
Elles ne supportent que ces modes de filtrage: GL_CLAMP, GL_CLAMP_TO_EDGE, and GL_CLAMP_TO_BORDER.
Elles ne peuvent avoir de bordure, mais franchement, ce n'est pas bien grave.
Il y a des priorités dans les types de textures. De la moins forte à la plus forte: GL_TEXTURE_1D, GL_TEXTURE_2D, GL_TEXTURE_RECTANGLE_ARB, GL_TEXTURE_3D, GL_TEXTURE_CUBE_MAP. Autrement dit: impérativement désactiver les tex3D et les cubemaps avant d'utiliser les texRect !!!
Les texRect sont répandues. Mais pour bien tester leur présence sur la CG, utiliser glGetBooleanv(GL_TEXTURE_RECTANGLE_ARB, &rect_supported);
Plus important ( vital ! )
Les coordonnées de textures ne sont pas normalisées de 0 à 1, mais de 0 à height et de 0 à width.
Pensez-y !

Enfin, c'est une très mauvaise idée d'abandonner subitement les POTS. Elles sont énormément plus rapides, et bénéficient en plus du mipmapping, le gain de vitesse est monstueux. Les NPOTS sont à réserver aux cas particuliers.

Voilà, il n'y a plus grand chose à dire pour une utilisation conventionnelle des textures rectangulaires. Mais il y a bien d'autres surprises, par exemple si vous voulez les utilisez pour les shaders.

Les Frambuffer Object

Il est IMPERATIF de tester si la carte supporte cette extension. Même si en 2011, les cartes qui ne la supportent pas sont tellement vieilles que vous feriez mieux d'abandonner tout support technique pour les dinosaures qui en auraient encore une.

Le test est relativement simple:

GLenum status;
status = glCheckFramebufferStatusEXT(GL_FRAMEBUFFER_EXT);
status==GL_FRAMEBUFFER_COMPLETE_EXT?
	std::cout << "fbo supporté\n":
	std::cout << "fbo non supporté\n";

(N'oubliez pas d'initialiser glew au préalable)
Si c'est bon, on peut alors en créer un.

GLuint fbo;
glGenFramebuffersEXT(1, &fbo);
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fbo);
glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT0_EXT,GL_TEXTURE_RECTANGLE_ARB, rect_tex, 0);

Vous remarquerez que, là encore, l'accès aux fonctionnalités d'openGL se fait via des integers, exactement de la même manière que les textures.
C'est peut-être un peu abstrait à manipuler au départ, mais je vous assure que l'on s'y fait vite.
D'ailleurs l'API elle-même est très similaire: glGenFrameBufferEXT, glBindFramebufferEXT... mis à part le Framebuffer et le EXT indiquant que cela ne fait pas partie de l'openGL de base, on ne se sent pas perdus.
La dernière ligne sert à dire que je dessinerai dans le framebuffer, ce sera en réalité dans la texture spécifiée.
Le premier paramètre est obligatoirement GL_FRAMEBUFFER_EXT, aussi stupide que cela _puisse_ paraître.
Le deuxième est GL_DEPTH_ATTACHMENT_EXT pour avoir accès au depth buffer, ou GL_COLOR_ATTACHMENT0_EXT pour la couleur normale.
le 3ème est le type de texture, GL_TEXTURE_2D ou GL_TEXTURE_RECTANGLE_ARB.
Le 4ème l'indice de la texture à utiliser.
Le dernier, enfin, détermine le niveau de mipmap dans lequel effectuer le dessin. Comme les textures rectangulaires ne permettent pas le mipmapping, ce sera forcément 0.

On va mainenant dessiner dans le fbo.

	glEnable(GL_TEXTURE_RECTANGLE_ARB);
	glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fbo);
	glDisable(GL_TEXTURE_RECTANGLE_ARB);
	glEnable(GL_TEXTURE_2D);
	// Dessin

On remarque qu'il est nécessaire que le type de texture utilisé par le fbo soit activé durant sa propre activation, mais après, on n'en a plus besoin. Il est même important de désactiver les textures rectangulaires, car sinon, comme précisé plus haut, ce paramètre aura précédence sur gl_texture_2d.

On va maintenant dessiner sur l'écran, avec notre texture toute neuve

	glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0); // cela dessine dans le buffer normal, c'est à dire l'écran.
	// Un dessin...
	glBindTexture(GL_TEXTURE_RECTANGLE_ARB,rect_tex);
	// un autre dessin, texturé avec cette texture-ci.
	// rappellez vous que les bornes sont [0..w] et [0..h] et non [0..1] !

Voilà ! rien de plus simple, n'est-ce pas ?
N'oubliez pas de fermer la porte en partant : glDeleteFramebuffersEXT(1, &fbo);
Nous sommes entre gentlemen, après tout.

Conclusion

Voici donc une autre méthode pour dessiner dans une texture. J'ai ai profité pour présenter ici les textures rectangulaires, car la plupart des effets nécessitant cette méthode ( ou une équivalente ) sont utilisés pour afficher cette texture en plein écran. Une POT n'est donc pas très appropriée.

• Elle est très peu connexe. Par exemple, il y a un unique lien vers la table des matières.
• Elle est peu explicite. Par exemple, dans l'interface de l'algorithme de dijkstra, on peut trouver un bgl_named_parameters. Il faut se lever de bonne heure pour trouver ce que c'est.
• Les exemples sont rares et peu explicites. Le seul exemple de l'algorithme A* est peu commenté (et encore moins aux parties les plus dures), démontre deux autres features qui n'ont rien à voir, utilise l'interface obsolète et non recommandée de la lib, et complique le tout avec une autre couche de templates totalement inutile pour un tuto qui se veut simple.

Ce tuto ci se veut simple. Il présente une des milliers de façons de procéder, que je considère comme simple, lisible et maintenable. Tous les membres du namespace boost seront préfixés par boost:: afin de savoir qu'est-ce qui est à nous et qu'est-ce qui est à Boost.

Il est basé sur le cas suivant : on a un graphe de waypoints, et on veut utiliser l'algorithme A* (qui utilise une bonne partie des concepts importants de la lib). Dans un premier temps, dans un souci de simplicité, on va utiliser une heuristique par défaut, qui rend toujours zéro. On verra par la suite comment l'adapter.

On va avoir besoin de deux headers boost:

#include <boost/graph/adjacency_list.hpp>
#include <boost/graph/astar_search.hpp>

On va maintenant définir les structures nécessaires à définir notre graphe :

// Un waypoint
struct WayPoint{
    Vector3f pos;
    // et éventuellement d'autres informations (crouch, hide, camp, ...)
};
 
// Une liaison entre deux waypoints
struct WayPointConnection{
    float dist;
    // idem
};

On va maintenant déclarer le type de notre graphe. On va utiliser une adjacency_list, qui est un peu un graphe à tout faire. Ce n'est pas le plus optimisé dans tous les cas, mais il est très versatile et convient très bien ici.

typedef boost::adjacency_list<  // adjacency_list est un template qui dépend de :
    boost::listS,               //  le conteneur utilisé pour les arcs partant d'un sommet. Ici, std::list.
    boost::vecS,                //  le conteneur utilisé pour contenir tous les sommets du graphe. Ici, std::vector.
    boost::undirectedS,         //  le type des arcs. Pourrait être boost::directedS.
    WayPoint,                   //  le type qui décrit un sommet.
    WayPointConnection          //  le type qui décrit un arc.
> WayPointGraph;

Les deux premiers paramètres influent grandement sur l'organisation mémoire et les performances de graphe. Selon les applications, une liste, un vecteur, un set, une map, ... sera plus approprié. Pour plus d'information, voir la doc.

On déclare aussi des raccourcis pour les IDs de sommets et d'arcs (en fait, ce sont des unsigned int)

typedef WayPointGraph::vertex_descriptor WayPointID;
typedef WayPointGraph::edge_descriptor   WayPointConnectionID;

On va pouvoir instancier notre graphe.

WayPointGraph graphe;

On commence par rajouter tous les sommets :

for (tous nos sommets S){
    WayPointID wpID = boost::add_vertex(graphe); // wp est l'indice d'un nouveau sommet qui a été ajouté dans graphe
    graphe[wpID].pos = la position du sommet S    // graphe[ un WayPointID ] est un WayPoint. On peut donc régler sa position de cette manière.
}

Maintenant, on peut les relier par des arcs. Là, c'est à vous de savoir où vont les arcs, boost ne va pas le deviner tout seul...

for (tous nos sommets U){ // petit changement de notation, dans boost un arc est souvent décrit entre deux sommets u et v.
    for (tous les voisins V de U){ // C'est à vous de savoir quels sont les voisins de U.
 
        WayPointID u = indice de U; // soit c'est le int du for(), soit il faut y accéder via un autre vector. Cf les notes plus bas.
        WayPointID v = indice de V;
 
        WayPointConnectionID edge;
        bool ok;
        boost::tie(edge, ok) = boost::add_edge(u,v, graphe); // boost::add_edge renvoie une std::pai>WayPointConnectionID,bool>. C'est compliqué à écrire, alors on laisse boost::tie le faire pour nous.
 
        if (ok)  // Si le graphe a bel et bien été ajouté ( pas de doublon, par exemple, sauf si spécifié dans le typedef de WayPointGraph )
        graphe[edge].dist = Distance(graphe[u].pos, graphe[v].pos); // Longueur d'un arc = distance euclidienne entre les deux sommets u et v.
 
    }
}

Plusieurs choses sont à remarquer :

• Personnellement, j'ai utilisé le fait que WayPointID est en fait un int et que dans mon double for(), j'utilise un int pour accéder au waypoint. C'est pas très propre, mais ça évite l'utilisation d'un vector en plus.
• graphe[edge] ( edge étant un WayPointConnectionID ) est un WayPointConnection, alors que graphe[u] (u étant un WaypointID) est un WayPoint. On peut donc accéder directement à leurs membres.
• Cette dernière remarque est très importante. Cette syntaxe est très appréciable, elle évite d'utiliser les incompréhensibles boost::property_map, elle oblige seulement à avoir un compilateur récent. GCC et Visual s'en sortent très bien.

Pour information, mon code à moi ressemble à ça :

for (int i=0; i<indices.size()/3; i++){
    ConnectiviteTriangle connectivity;
    fillconnectivityinfo(i, connectivity, indices);
    for (int c=0; c!=3; c++){
        if (connectivity.connexe[c]!=-1){
        TriangleDescriptor u = i;
        TriangleDescriptor v = connectivity.connexe[c];

La syntaxe est moyennement cool, mais j'espère que ça vous aidera à mieux comprendre.

Ok, donc maintenant notre graphe a des sommets et des arcs. On va pouvoir faire du pathfinding !

Pour ça, on va avoir besoin de quelques structures :

// Une instance de cette structure sera lancée en exception quand on aura trouvé un chemin
struct found_goal {};
 
// Le visiteur, dont le but est de définir une fonction examine_vertex qui dit si on est arrivé au but.
// Le but est spécifié via le constructeur.
class astar_goal_visitor : public boost::default_astar_visitor{
public:
    astar_goal_visitor(WayPointID goal) : m_goal(goal) {}
 
    void examine_vertex(WayPointID u, const Graph & g){ // Le const est important.
        if(u == m_goal)
            throw found_goal(); // On sort en lancant une exception. C'est moche mais c'est comme ça.
        }
private:
    WayPointID m_goal;
};

Il faut maintenant trouver notre point de départ et notre point d'arrivée. C'est votre problème, mais il faut arriver à quelque chose du style :

TriangleDescriptor goal = ...
TriangleDescriptor start = ...

Ok, on y va :

// Deux vecteurs qui vont servir à sauvegarder le résultat de la recherche
vector<WayPointID> p(boost::num_vertices(graphe)); // Les prédécesseurs
vector<float>      d(boost::num_vertices(graphe)); // Les distances
 
try { // Encore une fois, la découverte d'un chemin est signalée par une exception, donc il faut un try/catch.
    boost::astar_search
    (
        graphe, // notre graphe
        start,  // notre point de départ
        boost::astar_heuristic<NavMeshGraph, float>(), // Une heuristique bidon qui renvoie toujours 0
        boost::predecessor_map(&p[0]).distance_map(&d[0]).visitor(astar_goal_visitor(goal)).weight_map(boost::get(&WayPointConnection::dist, graphe)) // Voir plus bas
    );
 
} catch(found_goal fg) { // On a trouvé un chemin
    // On suit le chemin trouvé dans le sens inverse
    std::list<WayPointID> shortest_path;
    for(WayPointID v = goal;; v = p[v]) {
        shortest_path.push_front(v);
        if(p[v] == v)
            break;
    }
 
    // et on l'affiche.
    std::list<WayPointID>::iterator spi = shortest_path.begin();
    for(++spi; spi != shortest_path.end(); ++spi)
        Log(*spi);
    Log("Total travel time: " , d[goal] );
}

Remarque sur la ligne bizarre:

- Ce ne sont pas des virgules, ce sont des points ! Il s'agit d'un seul objet auquel on rajoute plein de propriétés. Cette syntaxe est par exemple utilisée dans la création d'interfaces graphiques : monmenu.addoption("option1").addoption("option2") etc
- A* a besoin de ces quatre propriétés : une map de prédécesseurs, une map de distances, une map de poids, et un visiteur.
- La map de poids est intrisèque au graphe : elle est stockée dans le champ dist des arcs. Mais Boost ne peut pas deviner tout seul que c'est cette variable qu'il faut lire, donc on le lui dit avec boost::get(&WayPointConnection::dist, graphe)
• Le visiteur est initialisé avec le goal pour pouvoir lancer son exception si il y a réussite.

Vous avez économisé 4 heures de prise de tête avec la doc de BGL, autant d'implémentation de l'A* si vous l'aviez codé vous même, et autant de débug que vous n'aurez jamais à faire : un des grands intérêts des templates, c'est que comme en OCaml, quand ça compile, ça marche (souvent) ^^.

Voyons maintenant comment améliorer un peu notre heuristique : pour l'instant, on n'a fait qu'un parcours brutal de l'arbre, ça ne valait pas trop le coup.
Cela va bien sûr passer par une nouvelle structure :

class distance_heuristic : public boost::astar_heuristic <WayPointGraph, float>{
public:
    // De la même manière que tout à l'heure, on passe les données dont il aura besoin dans son foncteur à la construction.
    distance_heuristic(const WayPointGraph & l, WayPointID goal)
    : m_graph(l), m_goal(goal) {}
 
    float operator()(WayPointID u)
    {
        const WayPoint & U = m_graph[u];
        const WayPoint & V = m_graph[m_goal];
        float dx = U.pos.x - V.pos.x;
        float dy = U.pos.y - V.pos.y;
        return sqrt(dx * dx + dy * dy);
    }
private:
    const WayPointGraph & m_graph;
    TriangleDescriptor m_goal;
}

m_graph peut être remplacé ( en changeant le constructeur et l'opérateur ) par n'importe quoi qui vous permette d'obtenir la position d'un vertex à partir de son identifiant. Cela peut être comme ici le graphe lui-même, mais aussi les données à partir duquel il a été construit, etc.

Il suffit maintenant de remplacer boost::astar_heuristic() par distance_heuristic(graphe, goal) dans l'appel au A*.

Oh, et au fait : les waypoints ça pue, utilisez des navmeshes.

Discussion sur le forum