WiiBuilder 1.10.0

La version 1.10.0 de WiiBuilder est maintenant disponible. Avant de mentionner la nouvelle fonctionnalité, je dois d’abord donner quelques explications.

Les fichiers de type WUHB (Wii U Homebrew Bundle) sont utilisés pour combiner le fichier RPX, l’écran de chargement, l’icône d’application, les informations du homebrew et jusqu’à 4Go de fichiers supplémentaires dans un nouveau format d’application homebrew. Le but est de faciliter la distribution de ceux-ci. Cette nouvelle solution est actuellement intégrée dans Aroma qui permet le chargement de ceux-ci à partir d’une carte SD. Aroma, qui est encore en version bêta au moment d’écrire ces lignes, permet aussi l’utilisation de modules et de plugins. Un des plugins intéressant est wiiload qui permet de démarrer une application qui a été transférée par le réseau directement à partir du Menu Wii U.

Maintenant, revenons à WiiBuilder. La nouvelle version permet d’envoyer ces fichiers .wuhb à une Wii U qui roule le plugin wiiload d’Aroma. Une fois le fichier reçu, le homebrew sera démarré.

WiiBuilder 1.10.0
La capture d’écran montre que le fichier wuhb a été envoyé à la Wii U avec succès.

WiiBuilder 1.9.0

La version 1.9.0 de WiiBuilder est maintenant disponible. Cette nouvelle version permet l’utilisation de tous les points de code disponibles dans Unicode.

WiiBuilder 1.9.0
WiiBuilder 1.9.0

Au départ, je croyais qu’il suffisait seulement d’ajouter deux caractères supplémentaires dans la zone d’entrée de texte comme je l’avais déjà fait dans la version 1.8.1. Je me suis trompé, ce fut pas mal plus compliqué.

Le problème, c’est que dans C++Builder, wchar_t est sur deux octets. Ce qui veut dire que sa valeur maximale est de 65535. La plupart des points de code des émojis se trouvent en haut de cette valeur. Il fallait donc que je trouve comment encoder ces points de code en UTF-16. Heureusement, la page Wikipedia de UTF-16 explique comment faire. Puisque je suis un peu paresseux, j’ai finalement pris une partie du code sur ce site web. Voici ce que ça donne dans une fonction C++Builder.

String __fastcall CodePointToString(uint32_t ACodePoint)
{
    static const uint32_t LEAD_OFFSET = 0xD800 - (0x10000 >> 10);

    String Result;

    if(ACodePoint > 0xFFFF)
    {
        wchar_t wc[3];
        wc[0] = LEAD_OFFSET + (ACodePoint >> 10);
        wc[1] = 0xDC00 + (ACodePoint & 0x3FF);
        wc[2] = L'\0';

        Result = String(wc);
    }
    else
    {
        Result = wchar_t(ACodePoint);
    }

    return Result;
}

WiiBuilder 1.8.2

La version 1.8.2 de WiiBuilder est maintenant disponible. Avant de mentionner la nouvelle fonctionnalité, je dois d’abord donner quelques explications.

Le toolchain wut qui fait maintenant partie de devkitPro permet de générer des fichiers RPX pour la Wii U. Un RPX est un fichier exécutable de format binaire. Il est généré à partir d’un fichier ELF temporaire. Il est similaire au format RPL (REL PLus), sauf qu’il possède un point d’entrée avec la fonction main().

L’application Homebrew Launcher, comme sont le nom l’indique, sert à démarrer des homebrews. Elle les charge à partir d’une carte SD ou directement à partir d’une connexion TCP/IP sur le port 4299. Depuis la version 1.4, les fichiers RPX peuvent être utilisés.

Maintenant, revenons à WiiBuilder. La nouvelle version permet d’envoyer des fichiers RPX à une Wii U qui roule l’application Homebrew Launcher. Une fois le fichier reçu, le homebrew sera démarré. Avant cette mise à jour, seuls les fichiers ELF pouvaient être chargés sur une Wii U.

WiiBuilder 1.8.2
La capture d’écran montre que le fichier boot.rpx a été envoyé à la Wii U avec succès.

WiiBuilder 1.8.1

La version 1.8.1 de WiiBuilder est maintenant disponible. Cette version nous permet d’entrer des nombres de cinq chiffres dans les champs Start et End. Cela est très pratique si on veut utiliser la police de caractères Font Awesome pour générer une image PNG à partir des icônes.

WiiBuilder with FontAwesome font
WiiBuilder avec la police de caractères FontAwesome

La fonction GRRLIB_DrawImg

Dans cet article, je tenterai d’expliquer l’utilisation de certains paramètres de la fonction GRRLIB_DrawImg de la bibliothèque GRRLIB.

Tout d’abord, voici le prototype de la fonction qui sert à dessiner une texture à l’écran:

void GRRLIB_DrawImg (
	const f32  	xpos,			// Position de l'image sur l'axe horizontal
	const f32  	ypos,			// Position de l'image sur l'axe vertical
	const GRRLIB_texImg *  tex,	// La texture à dessiner
	const f32  	degrees,		// La rotation en degré
	const f32  	scaleX,			// Proportion sur l'axe horizontal
	const f32  	scaleY,			// Proportion sur l'axe vertical
	const u32  	color			// La couleur
)

Le dernier paramètre de la fonction, color, sert à changer la couleur d’une texture. Le format de la couleur est le codage RGBA, qui est codé sur 4 octets (32 bits). Le premier octet représente le rouge, le second le vert, le troisième le bleu et finalement le dernier octet est pour l’opacité. 0 veut dire que la couleur n’est pas présente, tandis que 255, FF en hexadécimal, signifie que l’intensité de la couleur est à son maximum. Pour le canal alpha, 0 veut dire que l’image sera complètement transparente, donc dans cet exemple, l’opacité sera fixée à 255.

À partir de l’image PNG suivante on va afficher à l’écran quatre fantômes de différentes couleurs.

Fantômes de Pac-Man
Fantômes de Pac-Man
Il suffit d’ajouter quelque lignes seulement pour faire un test. Les lignes surlignées sont celles ajoutées au code du template du dossier examples de GRRLIB.

#include <grrlib.h>

#include <stdlib.h>
#include <wiiuse/wpad.h>

#include "ghost.h"

int main(int argc, char **argv) {
    // Initialise the Graphics & Video subsystem
    GRRLIB_Init();

    // Initialise the Wiimotes
    WPAD_Init();

    GRRLIB_SetBackgroundColour(0xFE, 0xCF, 0x07, 0xFF);
    GRRLIB_texImg *Fantome = GRRLIB_LoadTexture(ghost);

    // Loop forever
    while(1) {

        WPAD_ScanPads();  // Scan the Wiimotes

        // If [HOME] was pressed on the first Wiimote, break out of the loop
        if (WPAD_ButtonsDown(0) & WPAD_BUTTON_HOME)  break;

        // -------------------------------------------------------------------
        // Place your drawing code here
        GRRLIB_DrawImg(50, 50, Fantome, 0, 1, 1, 0xEF1E23FF); // Blinky
        GRRLIB_DrawImg(50, 250, Fantome, 0, 1, 1, 0xEE5395FF); // Pinky
        GRRLIB_DrawImg(250, 50, Fantome, 0, 1, 1, 0x6ECEDEFF); // Inky
        GRRLIB_DrawImg(250, 250, Fantome, 0, 1, 1, 0xF67E1FFF); // Clyde
        // -------------------------------------------------------------------

        GRRLIB_Render();  // Render the frame buffer to the TV
    }

    GRRLIB_FreeTexture(Fantome);
    GRRLIB_Exit(); // Be a good boy, clear the memory allocated by GRRLIB

    exit(0);
}

Le code est assez simple: à l’aide de la fonction GRRLIB_SetBackgroundColour on choisit une couleur d’arrière plan. Une texture est créée à la ligne 16 qui sera utilisée pour dessiner les fantômes aux lignes 28 à 31. Finalement la texture est détruite à la ligne 37.

Voici une capture d’écran du résultat final sous l’émulateur Dolphin révision 6972.
Dolphin avec les fantômes de Pac-Man

Une autre petite astuce est d’utiliser les paramètres scaleX et scaleY pour faire pivoter respectivement la texture horizontalement et verticalement. Pour effectuer cela il suffit de mettre une valeur négative. J’ai fait un petit bout de code qui déplace un fantôme de gauche à droite. Lorsque le fantôme se dirige vers la gauche, il regarde dans cette direction, même si sur l’image originale il regarde vers la droite.

#include <grrlib.h>

#include <stdlib.h>
#include <wiiuse/wpad.h>

#include "ghost.h"

typedef enum DirectionX {dGauche, dDroite} DirectionX;

int main(int argc, char **argv) {
    // Initialise the Graphics & Video subsystem
    GRRLIB_Init();

    // Initialise the Wiimotes
    WPAD_Init();

    GRRLIB_SetBackgroundColour(0xFE, 0xCF, 0x07, 0xFF);
    GRRLIB_texImg *Fantome = GRRLIB_LoadTexture(ghost);
    GRRLIB_SetMidHandle(Fantome, true);

    f32 Xposition = 0.0f;   // Position de l'image sur l'axe horizontal
    f32 FlipImage = 1.0f;   // Retourne l'image horizontalement
    DirectionX Direction = dDroite; // Direction (gauche ou droite)

    // Loop forever
    while(1) {

        WPAD_ScanPads();  // Scan the Wiimotes

        // If [HOME] was pressed on the first Wiimote, break out of the loop
        if (WPAD_ButtonsDown(0) & WPAD_BUTTON_HOME)  break;

        // --------------------------------------------------------------------
        if(Xposition < Fantome->w / 2.0f) {
            Xposition = Fantome->w / 2.0f;
            Direction = dDroite; // On change la direction
            FlipImage = 1.0f;    // Le fantôme regarde vers la droite
        }
        else if(Xposition > (rmode->fbWidth - (Fantome->w / 2.0f))) {
            Xposition = rmode->fbWidth - (Fantome->w / 2.0f);
            Direction = dGauche; // On change la direction
            FlipImage = -1.0f;   // Le fantôme regarde vers la gauche
        }
        if(Direction == dGauche)
            Xposition -= 1.5f; // On se déplace un peu plus vers la gauche
        else
            Xposition += 1.5f; // On se déplace un peu plus vers la droite
        GRRLIB_DrawImg(Xposition, 150, Fantome, 0, FlipImage, 1, 0xEF1E23FF);
        // --------------------------------------------------------------------

        GRRLIB_Render();  // Render the frame buffer to the TV
    }

    GRRLIB_FreeTexture(Fantome);
    GRRLIB_Exit(); // Be a good boy, clear the memory allocated by GRRLIB

    exit(0);
}

Lorsque le fantôme atteint la gauche de l’écran du téléviseur, on entre dans la condition à la ligne 34. Quand on arrive à la droite, c’est la condition de la ligne 39 qui est vraie. L’image devrait être dessinée 50 ou 60 fois par seconde dépendant si l’affichage de votre téléviseur est 50 ou 60 Hz. En anglais on parle de FPS (frame per second). La valeur 1.5 aux lignes 45 et 47 correspond à la vitesse de déplacement de l’image, elle est calculée en nombre de pixels par frame.

La fonction GRRLIB_DrawImg est la base de tout jeu 2D conçu avec GRRLIB, donc il est important de bien la comprendre. J’espère que cet article vous a aidé.

Dolphin et les homebrews

Dans un article précédent j’avais mentionné que l’émulateur Dolphin avait un problème avec l’infrarouge de la Wii Remote. Eh bien ce problème a été réglé. En effet, il est désormais possible de contrôler le pointeur d’une Wii Remote à l’aide de la souris de votre ordinateur. C’est un avancement formidable pour ceux qui testent leur homebrew avec ce logiciel.

C’est un programmeur du nom de godisgovernment qui a finalement fixé le problème à la révision 6177. Cette modification ne fait donc pas partie de la version 2.0, qui est la dernière version officielle à être distribuée. Les dernières versions de Dolphin sous Subversion sont quand même disponibles en téléchargement à partir de ce site Web.

Étant donné que ce n’est pas mon habitude de terminer un article sans code, je vous laisse avec un programme qui vous permettra de faire vous-même le test sous Dolphin. La bibliothèque GRRLIB sera utilisée pour la partie graphique. Comme pour tous les homebrews sur la Wii, c’est wiiuse qui servira pour la communication avec la Wii Remote.

#include <grrlib.h>
#include <stdlib.h>
#include <wiiuse/wpad.h>

#include "player1_point_png.h"

#define HOTSPOTX 48 // Cursor hot spot for x coordinate
#define HOTSPOTY 48 // Cursor hot spot for y coordinate

int main(int argc, char **argv) {
    // Initialise the Graphics & Video subsystem
    GRRLIB_Init();

    GRRLIB_texImg *Cursor0 = GRRLIB_LoadTexture(player1_point_png);
    GRRLIB_SetHandle(Cursor0, HOTSPOTX, HOTSPOTY);// Not needed, by default center is selected

    // Initialise the Wiimotes
    WPAD_Init();
    WPAD_SetDataFormat(WPAD_CHAN_ALL, WPAD_FMT_BTNS_ACC_IR);
    WPAD_SetVRes(WPAD_CHAN_ALL, rmode->fbWidth, rmode->efbHeight);

    // Loop forever
    while(1) {
        WPAD_ScanPads();  // Scan the Wiimotes
        WPADData *WPadData0 = WPAD_Data(WPAD_CHAN_0);

        // If [HOME] was pressed on the first Wiimote, break out of the loop
        if (WPadData0->btns_d & WPAD_BUTTON_HOME)  break;

        // ---------------------------------------------------------------------
        if(WPadData0->ir.valid) {
            GRRLIB_DrawImg(WPadData0->ir.x - HOTSPOTX,
                WPadData0->ir.y - HOTSPOTY, Cursor0,
                WPadData0->ir.angle, 1, 1, 0xFFFFFFFF);
        }
        // ---------------------------------------------------------------------

        GRRLIB_Render();  // Render the frame buffer to the TV
    }

    GRRLIB_Exit(); // Be a good boy, clear the memory allocated by GRRLIB

    GRRLIB_FreeTexture(Cursor0);

    exit(0);
}

À la ligne 14 on charge l’image dans une texture. L’image utilisée pour le pointeur est celle-ci:

Player 1 Wii pointer

Il s’agit d’une image qui fait partie d’un ensemble de curseurs pour la Wii conçus par drmr. Toutes les images sont de 96×96 pixels et le point sensible, habituellement le bout du doigt, est situé au centre. L’auteur a renoncé à ses droits sur les images pour les mettre dans le domaine public. Vous pouvez donc les utiliser dans vos applications sans problème de copyright.

À la ligne 19 on spécifie le format des données qui seront prises sur la Wii Remote. BTNS_ACC_IR veut dire boutons + accéléromètre + infrarouge. Par la suite, la fonction WPAD_SetVRes sert à définir la résolution d’écran virtuel pour la localisation de l’infrarouge. Pour ces opérations on utilise le paramètre WPAD_CHAN_ALL pour que tous les contrôleurs soient affectés. Pour que la fonction affecte une télécommande en particulier on doit utiliser WPAD_CHAN_0, WPAD_CHAN_1, WPAD_CHAN_2 ou WPAD_CHAN_3.

À la ligne 25 on va chercher les données de la première Wii Remote avec la fonction WPAD_Data. Les lignes 31 à 35 servent à faire afficher le curseur avec le bon angle à la position vers laquelle la télécommande pointe. Et ce, seulement si les coordonnés sont valides. Donc, si vous mettez votre main devant la Wii Remote, le pointeur disparaîtra de l’écran de votre téléviseur.

J’aurais pu ajouter bien des choses dans le code, mais j’ai décidé de le garder simple.

Bonne programmation…

Écrire du texte avec GRRLIB

Il existe trois manières différentes d’écrire du texte à l’aide de la bibliothèque GRRLIB. On peut utiliser une texture, un fichier BMF ou un fichier TTF. Chacune de ces méthodes possède des avantages et des inconvénients.

La première méthode qui sera expliquée sera l’utilisation d’une texture. Bien sûr, lorsqu’on parle de texture, on parle d’une image. Même si GRRLIB supporte les formats JPEG et Bitmap, il serait préférable que celle-ci soit en format PNG, car ce format permet l’utilisation de transparence. Il existe plusieurs logiciels qui permettent de générer de telles images. Celui que j’utilise est WiiBuilder. Voici l’image qui sera utilisée pour cet article:
Police de caractères pour GRRLIB Vous pouvez vous rendre compte de certaines limites simplement en regardant l’image. Tous les caractères qui seront nécessaires dans l’application devront être générés dans l’image. Dans celle-ci, il n’y a que les caractères 32 à 128, qui sont les caractères visibles du code ASCII. Donc, pas question d’utiliser un E accent aigu ou un A accent grave. Ces caractères auraient pu être générés, mais l’image aurait été plus grande.

Le plus grand inconvénient à utiliser une image est que chaque caractère doit avoir la même largeur. Dans l’exemple ci-dessus, c’est 13 pixels. Cela veut dire que même si on décide d’afficher un i ou un !, ils vont prendre la même place qu’un m ou w, qui sont généralement plus grand. Donc, à l’écran le mot Wii, pourrait avoir l’air de "W i i ". Bien sûr cela dépend toujours de la police utilisée. Dans celle que j’ai choisie, tous les caractères ont sensiblement la même largeur. On dit que c’est une police d’écriture à chasse fixe.

Il faut convertir l’image en fichier d’entête et la transformer en texture à l’aide de la fonction GRRLIB_LoadTexture. Ces manipulations ont déjà été abordées dans un article précédent, donc veuillez vous y référer si vous avez besoin d’aide. Il existe deux différences entre l’affichage de texte et l’affichage d’images. La première est qu’après avoir chargé l’image dans une structure de type GRRLIB_texImg, il faut spécifier les détails de notre image avec la fonction GRRLIB_InitTileSet. Les paramètres de la fonction dans l’ordre sont un pointeur vers la texture, la largeur et la hauteur d’un caractère et le caractère de départ. La seconde différence est l’utilisation de GRRLIB_Printf au lieu de GRRLIB_DrawImg.

Voici donc le code. Les lignes surlignées sont celles ajoutées au code du template du dossier examples de GRRLIB.

#include <grrlib.h>

#include <stdlib.h>
#include <wiiuse/wpad.h>

#include "demofont.h"

int main(int argc, char **argv) {
    // Initialise the Graphics & Video subsystem
    GRRLIB_Init();

    GRRLIB_texImg *demo_font = GRRLIB_LoadTexture(demofont);
    GRRLIB_InitTileSet(demo_font, 13, 23, 32);

    // Initialise the Wiimotes
    WPAD_Init();

    // Loop forever
    while(1) {

        WPAD_ScanPads();  // Scan the Wiimotes

        // If [HOME] was pressed on the first Wiimote, break out of the loop
        if (WPAD_ButtonsDown(0) & WPAD_BUTTON_HOME)  break;

        // ---------------------------------------------------------------------
        // Place your drawing code here
        GRRLIB_Printf(5, 100, demo_font, 0xFFFFFFFF, 1,
            "Ceci est un test de texture");
        // ---------------------------------------------------------------------

        GRRLIB_Render();  // Render the frame buffer to the TV
    }

    GRRLIB_FreeTexture(demo_font);
    GRRLIB_Exit(); // Be a good boy, clear the memory allocated by GRRLIB

    exit(0);
}

Cela fait le tour de la première méthode. La prochaine dont il va être question est l’utilisation de fichier BMF pour afficher du texte. BMF est l’extension qui désigne un bitmap font. Ce type de fichier peut être téléchargé sur le site Web suivant: http://bmf.wz.cz. La police que j’ai choisie se nomme NOSTK. Elle possède seulement 35 caractères et les lettres minuscules ne sont pas présentes.

Les étapes pour afficher du texte sont assez simples. Encore une fois, on transforme le fichier en entête qui sera inclus dans le main.c. On charge l’image dans une structure. Cette fois-ci, il s’agit d’un GRRLIB_bytemapFont. On dessine le texte avec GRRLIB_PrintBMF et la mémoire est libérée grâce à GRRLIB_FreeBMF.

Voici le code avec les nouvelles lignes surlignées:

#include <grrlib.h>

#include <stdlib.h>
#include <wiiuse/wpad.h>

#include "demofont.h"
#include "nostk.h"

int main(int argc, char **argv) {
    // Initialise the Graphics & Video subsystem
    GRRLIB_Init();

    GRRLIB_texImg *demo_font = GRRLIB_LoadTexture(demofont);
    GRRLIB_InitTileSet(demo_font, 13, 23, 32);
    GRRLIB_bytemapFont *bmf_font = GRRLIB_LoadBMF(nostk);

    // Initialise the Wiimotes
    WPAD_Init();

    // Loop forever
    while(1) {

        WPAD_ScanPads();  // Scan the Wiimotes

        // If [HOME] was pressed on the first Wiimote, break out of the loop
        if (WPAD_ButtonsDown(0) & WPAD_BUTTON_HOME)  break;

        // ---------------------------------------------------------------------
        // Place your drawing code here
        GRRLIB_Printf(10, 100, demo_font, 0xFFFFFFFF, 1,
            "Ceci est un test de texture");
        GRRLIB_PrintBMF(10, 150, bmf_font,
            "CECI EST UN TEST DE FICHIER BMF");
        // ---------------------------------------------------------------------

        GRRLIB_Render();  // Render the frame buffer to the TV
    }

    GRRLIB_FreeTexture(demo_font);
    GRRLIB_FreeBMF(bmf_font);
    GRRLIB_Exit(); // Be a good boy, clear the memory allocated by GRRLIB

    exit(0);
}

La dernière méthode est l’utilisation de fichier TTF. TTF est l’extension pour désigner une police de caractères de format TrueType. Les polices TrueType sont constituées de vecteurs donc la qualité du texte ne diminue pas contrairement au bitmap lorsque la taille augmente. La police que j’ai choisie se nomme Miama et elle possède 1110 caractères. Par contre, sa taille est de 106 Ko, ce qui reste quand même raisonnable. Elle a été téléchargée sur le site Open Font Library.org.

Les étapes pour afficher du texte sont les mêmes que pour les BMF, sauf que l’on remplace le mot BMF par TTF. On charge l’image dans une structure de type GRRLIB_ttfFont avec la fonction GRRLIB_LoadTTF. On dessine le texte avec GRRLIB_PrintfTTF et la mémoire est libérée grâce à GRRLIB_FreeTTF. Il est possible d’utiliser des chaînes de caractères de type wchar_t avec la fonction GRRLIB_PrintfTTFW.

Voici le code avec les nouvelles lignes surlignées:

#include <grrlib.h>

#include <stdlib.h>
#include <wiiuse/wpad.h>

#include "demofont.h"
#include "nostk.h"
#include "Miama.h"

int main(int argc, char **argv) {
    // Initialise the Graphics & Video subsystem
    GRRLIB_Init();

    GRRLIB_texImg *demo_font = GRRLIB_LoadTexture(demofont);
    GRRLIB_InitTileSet(demo_font, 13, 23, 32);
    GRRLIB_bytemapFont *bmf_font = GRRLIB_LoadBMF(nostk);
    GRRLIB_ttfFont *ttf_font = GRRLIB_LoadTTF(Miama, Miama_size);

    // Initialise the Wiimotes
    WPAD_Init();

    // Loop forever
    while(1) {

        WPAD_ScanPads();  // Scan the Wiimotes

        // If [HOME] was pressed on the first Wiimote, break out of the loop
        if (WPAD_ButtonsDown(0) & WPAD_BUTTON_HOME)  break;

        // ---------------------------------------------------------------------
        // Place your drawing code here
        GRRLIB_Printf(10, 100, demo_font, 0xFFFFFFFF, 1,
            "Ceci est un test de texture");
        GRRLIB_PrintBMF(10, 150, bmf_font,
            "CECI EST UN TEST DE FICHIER BMF");
        GRRLIB_PrintfTTF(10, 200, ttf_font,
            "Ceci est un test de police TrueType", 60, 0xFFFFFFFF);
        // ---------------------------------------------------------------------

        GRRLIB_Render();  // Render the frame buffer to the TV
    }

    GRRLIB_FreeTexture(demo_font);
    GRRLIB_FreeBMF(bmf_font);
    GRRLIB_FreeTTF(ttf_font);
    GRRLIB_Exit(); // Be a good boy, clear the memory allocated by GRRLIB

    exit(0);
}

L’encodage par défaut des fichiers dans Programmer’s Notepad pourrait vous causer des problèmes avec certains caractères de la langue française. Si c’est la cas, il faut donc aller dans File / Properties… ou sinon utiliser le raccourci Alt + Entrée avec le bon fichier ouvert. Au lieu de Default dans la liste Encoding, vous pouvez sélectionner UTF-8. Si vous désirez ne pas altérer votre fichier qui contient le code, vous pouvez alors créer un fichier d’entête avec l’encodage de votre choix qui contiendra tout le texte dans des directives #define.

Je vous laisse avec une image du résultat final.
Texte avec GRRLIB

Configurer Programmer’s Notepad pour lancer Indent

Lors d’un article précédent, j’avais expliqué comment démarrer Dolphin à partir de Programmer’s Notepad. Voici maintenant un article similaire qui vous expliquera comment lancer Indent à partir de ce même éditeur.

Tout d’abord, un petit mot à propos d’Indent. Indent est un logiciel de mise en forme de codes source. Il change l’apparence d’un programme codé en C en y insérant ou en effaçant des espaces et des retours à la ligne. Il peut être utilisé afin de rendre votre code plus facile à lire et aussi pour changer le style d’écriture vers un autre.

La première étape consiste à télécharger Indent. Pour télécharger la version pour Windows, il suffit d’aller sur ce site Web. Lors de l’écriture de cet article, la dernière version disponible était la 2.2.10. Les fichiers zip que je vous conseille de télécharger sont Binaries et Dependencies. Sur votre disque dur, créez un nouveau dossier, par exemple: C:\indent. Dans le fichier indent-2.2.10-bin.zip, il faut extraire le fichier indent.exe qui se trouve dans le dossier bin. Dans le fichier qui contient les dépendances (indent-2.2.10-dep.zip), il faut extraire les fichiers libiconv2.dll et libintl3.dll qui se trouvent dans le dossier bin. Maintenant, votre dossier C:\indent devrait contenir le minimum requis pour faire fonctionner Indent.

Programmer’s Notepad, ajout de Indent

Indent est prêt à être utilisé, alors voici comment faire pour le démarrer à partir de Programmer’s Notepad:

  • Ouvrir Programmer’s Notepad
  • Ouvrir la fenêtre d’options en allant dans Tools / Options
  • Sélectionner Tools dans la structure arborescente
  • Sélectionner C / C++ dans la liste déroulante Scheme
  • Cliquer sur le bouton Add
  • Entrer les informations suivantes
    • Name: Format Source
    • Command: C:\indent\indent.exe
    • Folder: %d
    • Parameters: -linux %f
    • Shortcut: CTRL + Shift + F
    • Save: Current File
    • Cocher This tool will modify the current file.
  • Cliquer sur OK pour fermer la fenêtre de propriété d’outils
  • Cliquer sur OK pour fermer la fenêtre d’options

La propriété Command doit être modifiée pour représenter le chemin d’accès de Indent sur votre disque dur. Pour Shortcut, j’ai décidé d’utiliser CTRL + Shift + F, F comme dans Format. Ne vous gênez pas pour mettre la touche de raccourci qui fait votre bonheur.

La propriété Parameters est sans doute la plus importante, car c’est là que le style de programmation y est décidé. Dans la configuration précédente, j’utilise -linux pour le style Linux. Il existe quelques autres styles communs:

  • GNU (style par défaut depuis la version 1.2): -gnu
  • Kernighan & Ritchie: -kr
  • Berkeley original: -orig

Chacun de ces styles est l’équivalent de plusieurs paramètres. Par exemple, le style Linux:

-nbad -bap -nbc -bbo -hnl -br -brs -c33 -cd33 -ncdb -ce -ci4 -cli0 -d0 -di1 -nfc1 -i8 -ip0 -l80 -lp -npcs -nprs -npsl -sai -saf -saw -ncs -nsc -sob -nfca -cp33 -ss -ts8 -il1

Pour plus de détails, veuillez vous référer à la documentation de Indent.

À partir de maintenant vous n’aurez plus d’excuses pour soumettre du code désorganisé.

Initiation à la bibliothèque GRRLIB

GRRLIB est une bibliothèque graphique codée en langage C pour la conception d’homebrews sur la Wii. Grâce à cette bibliothèque, l’utilisation des fonctions GX n’est plus nécessaire. GX est la bibliothèque graphique de Nintendo qui interface le processeur graphique de la console.

GRRLIB est un projet à code source ouvert qui est hébergé sur le site Web de GitHub. La dernière version stable est disponible en téléchargement sous forme de fichier compressé et la version en développement peut être récupérée sous Subversion.

Pour compiler GRRLIB, il faut d’abord que devkitPro avec les composants devkitPPC, libogc et libfat soit installé sur votre PC. devkitPPC permet la compilation de code pour l’architecture powerpc-eabi. La bibliothèque libogc assure un support pour les fonctions GX et libfat permet l’utilisation du système de fichiers FAT.

Lors de son installation, GRRLIB va installer d’autres bibliothèques telles que libjpeg pour l’utilisation de fichiers JPEG, libpngu qui nécessite libpng et zlib pour l’utilisation d’images PNG et enfin FreeType pour l’utilisation de polices de caractères TrueType.

Pour lancer l’installateur, ouvrez une invite de commandes dans le dossier GRRLIB et tapez la ligne suivante:
make clean all install
Ceci pourrait prendre un peu de temps dépendant de la puissance de votre ordinateur. Quand le défilement de commande cessera, cela voudra dire que tout est installé. Les bibliothèques devraient avoir été copiées dans le dossier C:\devkitPro\libogc\lib\wii et les fichiers d’entête dans le dossier C:\devkitPro\libogc\include.

Pour ceux qui n’ont rien compris au dernier paragraphe, vous pouvez créer un fichier nommé install.bat dans le dossier GRRLIB et y insérer le code suivant:

@echo off
echo Nettoyage de l'installation pr‚c‚dente
make clean -s
echo Compilation du code source
make -s
echo Installation des bibliothŠques dans le dossier de libogc
make install -s

Ensuite, il suffit de double-cliquer sur le fichier pour démarrer l’installation de GRRLIB.

Vous êtes maintenant prêts à commencer à programmer un homebrew pour la Wii à l’aide de GRRLIB. Dans le dossier examples, il y a un projet Programmer’s Notepad qui contient le code minimum pour utiliser GRRLIB. Le projet se nomme template.pnproj et il est situé à l’intérieur du dossier template. Le projet inclut les fichiers main.c et Makefile. Ces fichiers devraient toujours être utilisés pour démarrer la programmation d’un nouveau jeu.

Maintenant, si vous faites Tools / make ou Alt+1, le projet se compilera et les fichiers template.elf et template.dol seront gérés. S’il y a une erreur, c’est que vous n’avez pas suivi les étapes correctement. Je vous conseille donc de lire attentivement le document README.html incorporé dans le téléchargement de GRRLIB. Si le problème persiste, vous pourrez toujours aller poser une question sur le forum officiel de la bibliothèque.

Les images ne sont pas utilisées directement dans GRRLIB. Il faut d’abord les transformer en texture avec la fonction GRRLIB_LoadTexture. Le résultat sera enregistré dans une structure de type GRRLIB_texImg. Il existe aussi des fonctions spécifiques pour les trois types d’image supportés par GRRLIB, soit GRRLIB_LoadTexturePNG, GRRLIB_LoadTextureJPG et GRRLIB_LoadTextureBMP. Si vous avez besoin de plus d’information sur les fonctions incluses dans la bibliothèque, il existe une documentation générée par Doxygen.

Avant d’incorporer une image à un projet, il faut savoir que ses dimensions doivent être inférieures ou égales à 1024 pixels. De plus, elles doivent être des multiples de quatre. Si l’image est un PNG, il faut aussi qu’elle soit en 24 ou 32 bits. Les palettes ne sont pas gérées par PNGU.

Les images peuvent être chargées à partir d’une carte SD avec la fonction GRRLIB_LoadTextureFromFile. Par contre, ce n’est pas cette façon qui sera démontrée ici. Les images seront ajoutées à l’intérieur des fichiers .elf et .dol dans le but d’avoir un seul fichier exécutable. Ceci permettra de tester plus facilement le homebrew dans Dolphin ou de l’exécuter sur la Wii à l’aide de wiiload.

Pour accomplir cette transformation, il existe quelques outils. raw2c est un utilitaire qui fonctionne par ligne de commandes et il est inclus dans le dossier bin de devkitPPC. WiiBuilder est un logiciel fonctionnant sous Windows qui permet de faire la même chose que raw2c en plus de plusieurs autres choses. Il est disponible en téléchargement sur le site Web de WiiBrew. Les avantages sont qu’il ne nécessite pas de lignes de commandes, qu’il donne des avertissements lorsque les images n’ont pas un format approprié et qu’il permet de générer seulement les fichiers d’entête. Le dernier point peut paraître inutile, mais cela fait en sorte que le fichier généré pourra être déplacé dans n’importe quel dossier sans avoir à modifier le Makefile pour ajouter un endroit supplémentaire à la compilation. La modification du fichier Makefile cause souvent des maux de tête au programmeur débutant, c’est pourquoi je ne parlerai pas de l’utilisation de bin2o pour générer un fichier objet qui inclut l’image.

Pour la démonstration, je vais me servir de l’image pirate.png qui se trouve dans le dossier \examples\bitmap_fx\source\gfx. Vous pouvez créer un dossier images à l’intérieur du dossier template dans lequel vous pourrez copier l’image. Si vous utilisez WiiBuilder, il suffit de faire un glisser-déposer de l’image à l’intérieur de la liste de la section File. Un fichier portant le nom de pirate.h devrait avoir été créé. C’est ce fichier qu’il faut ajouter dans main.c.

Passons maintenant à la programmation. Pour afficher l’image, il suffit d’ajouter quatre lignes au code du template. On ajoute à la liste d’entête celui-ci:

#include "../images/pirate.h"

Après la commande GRRLIB_Init, il faut ajouter ceci pour charger la texture:

GRRLIB_texImg *MaTexture = GRRLIB_LoadTexture(pirate);

À l’endroit où il est écrit « Place your drawing code here », on met le code suivant pour dessiner la texture à l’écran:

GRRLIB_DrawImg(100, 100, MaTexture, 0, 1, 1, 0xFFFFFFFF);

Finalement, on ajoute le code suivant à la suite de GRRLIB_Exit pour libérer la mémoire attribuée par GRRLIB_LoadTexture:

GRRLIB_FreeTexture(MaTexture);

Si vous utilisez l’émulateur Dolphin vous devriez avoir le résultat suivant:

L'émulateur Dolphin qui roule un homebrew assez simple

Ce n’est pas ce qu’on pourrait qualifier de meilleur homebrew au monde, mais au moins c’est un point de départ. Si vous êtes intéressés a continuer, allez regarder les autres exemples inclus avec GRRLIB.

Bonne chance dans la programmation de votre jeu révolutionnaire!

Programmer’s Notepad 2.1.3

Depuis le 11 mars, la version 2.1.3 de Programmer’s Notepad est disponible en téléchargement. Je désire vous en informer pour faire suite à mon article sur ce logiciel.

Programmer’s Notepad version 2.1.3

Si vous ne voulez pas perdre les configurations effectuées pour démarrer vos outils préférés, vous allez devoir copier le fichier UserTools.xml qui se trouve dans le dossier settings avant de supprimer l’ancienne version du logiciel. Ensuite, faites l’installation de la nouvelle version et écrasez le fichier existant avec votre copie de sauvegarde.

Si vous avez un peu de temps devant vous et que vous possédez une bonne connaissance de la langue de Molière, il vous est alors possible de participer à la traduction du logiciel en français. Présentement, les seules langues disponibles sont l’anglais, le chinois et le hongrois. Le format PO est utilisé pour la traduction. Plusieurs éditeurs le reconnaissent dont Poedit qui est multiplate-forme. Pour plus de détails, il existe une page Web qui vous explique comment faire.