[nRGBlib] W.I.P - Bibliothèque couleurs pour Ndless 3.1

[totorigolo]

J'ai modifié le post de présentation : http://tiplanet.org/forum/viewtopic.php?f=20&t=8597&p=119024#p119024

J'ai créé une vraie présentation en plusieurs parties.

[totorigolo]

Nouvelle vidéo ajouté dans le topic de présentation, par rapport à la compatibilité Nspire CX / Nspire Classique.

( http://www.youtube.com/watch?v=R5gHYONwilg )

Je fais cette compatibilité grâce à la formule : color = ((R + G + B) / 3) / 16; puis j'utilise le code setPixel() de Ndless 2.1.
Je vais aussi modifié ma structure Color pour pouvoir faire ça :

Code: Tout sélectionner

    //...
    Color appleCol; // Rouge pour CX et noir pour classique
        appleCol.R = 255; // |
        appleCol.G = 0;   // |-> Rouge
        appleCol.B = 0;   // |
        appleCol.BW = 0; // Noir

    drawQQchoseColor(x, y, appleCol);
    //...

[totorigolo]

Préférez-vous que les fonctions soit surchargés :

Code: Tout sélectionner

void drawLineRGB_(short x1, short y1, short x2, short y2, char R, char G, char B);
inline void drawLine_(short x1, short y1, short x2, short y2, Color col);
inline void drawLineRGB(Line *l, char R, char G, char B);
inline void drawLine(Line *l, Color col);

ou uniques :

Code: Tout sélectionner

void drawLine(Line *l, Color col);

? Et dans quel ordre d'importance/utilisation les trieriez-vous ? C'est-à-dire vous utiliserez plus, dans l'exemple d'en haut, quelle fonction ?

EDIT : J'ai plus long

Code: Tout sélectionner

void drawStrBckgRGB(short x, short y, char *str, char size, char endl, char R, char G, char B, char BW, char Rb, char Gb, char Bb, char BWb);

[Levak]

Est-ce que c'est Color > char ou bien char > Color la surcharge ?

Dans ce cas, si c'est de Color vers char ça peut être utiles, pour certains, de les laisser (pour ne pas avoir à travailler avec des couleurs à allouer etc ...). Par contre, l'inverse est, je pense, en trop (niveau opti).

[Lionel Debroux]

Il faut essayer de limiter le nombre d'arguments à une méthode, sinon l'efficacité du passage de paramètres s'en ressent
(oui, je sais, les fonctions d'ExtGraph qui prennent des plans, des sprites et des masques séparés ne suivent pas ceci ^^)

Pense à t'appuyer sur le compilateur: une macro "RGB(r, g, b)" peut transformer R, G, B en une couleur, et être optimisée en temps de compilation si ces valeurs sont des constantes

La fonction canonique est donc

Code: Tout sélectionner

void drawLine_(short x1, short y1, short x2, short y2, Color col);

et toutes les autres fonctions peuvent être écrites en fonction d'elle.

Code: Tout sélectionner

inline void drawLineRGB(Line *l, Color col);

va nécessiter des écritures en mémoire pour créer la ligne et des lectures pour obtenir les paramètres... c'est moins efficace

Pour le dessin de strings, tu peux t'en sortir avec des setters pour la couleur de foreground et la couleur de background (là encore, en prenant un seul paramètre pour définir la couleur). C'est ce que font nombre de fonctions de dessin de texte depuis très longtemps (voir le standard ANSI)

[totorigolo]

Est-ce que c'est Color > char ou bien char > Color la surcharge ?

La surcharge, c'est de Color vers RGB : exemple avec DrawBox :

Code: Tout sélectionner

void drawBoxRGB_(short x, short y, short w, short h, char R, char G, char B)
{
    short i, j;
    for (i = x; i < (x + w); i++)
    {
        for (j = y; j < (y + h); j++)
        {
            setPixelRGB(i, j, R, G, B);
        }
    }
}
inline void drawBox_(short x, short y, short w, short h, Color col)
{
    drawBox2DRGB(x, y, w, h, col.R, col.G, col.B);
}
inline void drawBoxRGB(Box *b, char R, char G, char B)
{
    drawBox2DRGB(box.x, box.y, box.w, box.h, R, G, B);
}
inline void drawBox(Box *b, Color col)
{
    drawBox2DRGB(box.x, box.y, box.w, box.h, col.R, col.G, col.B);
}

Donc si j'ai bien compris tu est pour celle-là.

Pense à t'appuyer sur le compilateur: une macro "RGB(r, g, b)" peut transformer R, G, B en une couleur, et être optimisée en temps de compilation si ces valeurs sont des constantes

Je ne vois pas comment créer une macro pour transformer RGB > Color. Alors que le contraire me parait assez simple : #define RGB(color) color.r, color.g, color.b.

<code de drawLineRGB> va nécessiter des écritures en mémoire pour créer la ligne et des lectures pour obtenir les paramètres... c'est moins efficace

J'ai créé ce type de fonctions, qui prennent en pointeur la forme à afficher, au cas où quelqu'un veuille créer une ligne et l'afficher plusieurs fois. Cela lui évite donc de créer lui-même les variables x1, y1, x2 et y2. Mais c'est fonction est (il me semble, grâce à inline) modifiée à la compilation en la fonction d'origine. (Je viens de penser à l'instant que je peux atteindre le même résultat grâce aux macros...)
Mais je n'ai pas l'habitude de programmer sur des plateformes où il faut faire attention à tout prix de la mémoire, etc parce que d'habitude je fais des petits trucs pour m'amuser sur PC, donc niveau optimisation...
Concrétement, je compte faire ça :

nGEO :

Show/Hide spoilerAfficher/Masquer le spoiler

Code: Tout sélectionner

#ifndef NGEO_H_INCLUDED
#define NGEO_H_INCLUDED

#include "nCOMMON.h"

typedef struct Line
{
    short x1;
    short y1;
    short x2;
    short y2;
} Line;
Line new_Line(short x1, short y1, short x2, short y2);
void init_Line(Line *l, short x1, short y1, short x2, short y2);

typedef struct Box
{
    short x;
    short y;
    short w;
    short h;
} Box;
Box new_Box(short x, short y, short w, short h);
void init_Box(Box *b, short x, short y, short w, short h);

typedef struct Square Square;
struct Square
{
    short x;
    short y;
    short c;
};
Square new_Square(short x, short y, short c);
void init_Square(Square *d, short x, short y, short c);

typedef struct Circle Circle;
struct Circle
{
    short x;
    short y;
    short radius;
};
Circle new_Circle(short x, short y, short radius);
void init_Circle(Circle *d, short x, short y, short radius);

typedef struct Disc Disc;
struct Disc
{
    short x;
    short y;
    short radius;
};
Disc new_Disc(short x, short y, short radius);
void init_Disc(Disc *d, short x, short y, short radius);

typedef struct Triangle Triangle;
struct Triangle
{
    short x1;
    short y1;
    short x2;
    short y2;
    short x3;
    short y3;
};
Triangle new_Triangle(short x1, short y1, short x2, short y2, short x3, short y3);
void init_Triangle(Triangle *t, short x1, short y1, short x2, short y2, short x3, short y3);

/// Dessine trois bandes RGB qui font chacunes 1 / 3 de l'écran
void RGBstrips();

/// Dessine une ligne quelconque en couleurs
void drawLineRGB_(short x1, short y1, short x2, short y2, char R, char G, char B);
inline void drawLine_(short x1, short y1, short x2, short y2, Color col);
inline void drawLineRGB(Line *l, char R, char G, char B);
inline void drawLine(Line *l, Color col);

/// Dessine un carré en couleur
inline void drawSquareRGB_(short x, short y, short c, char R, char G, char B);
inline void drawSquare_(short x, short y, short c, Color col);
inline void drawSquareRGB(Square *s, char R, char G, char B);
inline void drawSquare(Square *s, Color col);

/// Dessine un rectangle en couleur
void drawBoxRGB_(short x, short y, short w, short h, char R, char G, char B);
inline void drawBox_(short x, short y, short w, short h, Color col);
inline void drawBoxRGB(Box *box, char R, char G, char B);
inline void drawBox(Box *box, Color col);

/// Dessine un cercle en couleur
void drawCircleRGB_(short x, short y, short radius, char R, char G, char B);
void drawCircle_(short x, short y, short radius, Color col);
void drawCircleRGB(Circle *c, char R, char G, char B);
void drawCircle(Circle *c, Color col);

/// Dessine un disque en couleur
void drawDiscRGB_(short x, short y, short radius, char R, char G, char B);
void drawDisc_(short x, short y, short radius, Color col);
void drawDiscRGB(Disc *d, char R, char G, char B);
void drawDisc(Disc *d, Color col);

/// Dessine un triangle vide en couleur
void drawTriangleRGB_(short x1, short y1, short x2, short y2, short x3, short y3, char R, char G, char B);
void drawTriangle_(short x1, short y1, short x2, short y2, short x3, short y3, Color col);
void drawTriangleRGB(Triangle *t, char R, char G, char B);
void drawTriangle(Triangle *t, Color col);

#endif // NGEO_H_INCLUDED


nGUI :

Show/Hide spoilerAfficher/Masquer le spoiler

Code: Tout sélectionner

#ifndef NGUI_H_INCLUDED
#define NGUI_H_INCLUDED

// Contient les alphabets
#include "charmap.h"
#include "nCOMMON.h"

/// Dessine une lettre aux position données en changeant la couleur de fond
void drawCharBckgRGB(short x, short y, char ch, char size, char R, char G, char B, char BW, char Rf, char Gb, char Bb, char BWb);
inline void drawCharBckg(short x, short y, char ch, char size, Color colC, Color colB);

/// Dessine une lettre aux positions données
void drawCharRGB(short x, short y, char ch, char size, char R, char G, char B);
inline void drawChar(short x, short y, char ch, char size, Color col);

/// Ecris un texte aux positions données en changeant la couleur de fond
///    - retour est un booléen qui défini si le retour à la ligne est permis
void drawStrBckgRGB(short x, short y, char* str, char size, char endl, char R, char G, char B, char BW, char Rb, char Gb, char Bb, char BWb);
inline void drawStrBckg(short x, short y, char* str, char size, char endl, Color colT, Color colF);

/// Ecris un texte aux positions données
///    - retour est un booléen qui défini si le retour à la ligne est permis
void drawStrRGB(short x, short y, char* str, char size, char endl, char R, char G, char B);
inline void drawStr(short x, short y, char* str, char size, char endl, Color col);

#endif // NGUI_H_INCLUDED


[Lionel Debroux]

Je n'ai pas encore regardé tes spoilers en détall car il faut que je parte, mais il faut prendre en compte dès le départ le fait que tu ne tournes pas sur PC, mais sur une plate-forme vraiment moins puissante (bien que ce soit la calculatrice la plus puissante du marché)

Pense bien que sur la Nspire, l'écran affiche, par défaut, les couleurs sur 16 bits. Avec des valeurs R, G et B sur 8 bits chacune, l'implémentation Lua de TI ment purement et simplement: elle effectue une conversion, qui droppe certainement les bits les moins significatifs des valeurs R, G, B qui lui sont passées.
Autrement dit, ta surcharge est dans le mauvais sens: pour écrire à l'écran, il faudra que tu produises une couleur de pixel, pas que tu écrives R, G et B comme des valeurs séparées

A la main, la conversion se fait comme suit: il y a 5 bits pour R, 6 bits pour G, 5 bits pour B. C'est parce que le vert est la couleur à laquelle l'oeil humain est le plus sensible. La conversion RGB -> couleur du pixel est donc:
* soit tu restreins les valeurs de R, G et B aux valeurs significatives, et donc c'est aussi simple que:

Code: Tout sélectionner

#define RGB(r, g, b) (((r) << 11) | ((g) << 5) | (b))

(ça, c'est en gros ce que ferait le compilo si Color était une struct contenant un bit field, et que tu veuilles faire rentrer des valeurs 0-31 dans color.r, 0-63 dans color.g et 0-31 dans color.b)

* soit tu fais ce que Lua doit faire, à savoir dropper les bits les moins significatifs pour faire rentrer le résultat sur 16 bits:

Code: Tout sélectionner

#define RGB(r, g, b) (((r & 0xF7) << (11 - 3)) | ((g & 0xFC) << (5 - 2)) | (b >> 3))

Show/Hide spoilerAfficher/Masquer le spoiler

(le premier qui me fait une remarque sur le fait que la précédence des opérateurs permettrait peut-être d'utiliser moins de parenthèses, a droit à une fessée virtuelle
Il faut toujours essayer d'écrire le code de manière à être sûr de ce qui se produit - et pour ça, utiliser plus de parenthèses pour forcer ce qu'on veut est intéressant.)

[Adriweb]

Juste une idée au niveau des fonctions, ca reste bizarre de devoir passer en arguemnt (3 args, même!) la couleur dans une fonction de tracage de ligne, par exemple.
Je trouve plus logique de faire comme ce que le Lua fait, c'est a dire, de "setColor" à un certain point, et tout ce qui se passe apres prendra la couleur qui sera définie.

Ou alors, si tu préfère rester dans le passage d'arguments, autant passer par une variable de type Color, au lieu d'un R, un G, et un B.
D'ailleurs, rendre cet argument non-obligatoire serait pas mal, et par exemple prendre la derniere couleur utilisée si celle-ci n'est pas précisée.

Tu en penses quoi ?

[Levak]

Juste une idée au niveau des fonctions, ca reste bizarre de devoir passer la couleur dans une fonction de tracage de ligne, par exemple.
Je trouve plus logique de faire comme ce que le Lua fait, c'est a dire, de "setColor" à un certain point, et tout ce qui se passe apres prendra la couleur qui sera définie.

Un portage de SDL ça passe par reprendre la logique de ses fonctions. Entre des paramètres globaux et des fonctions aux paramètres locaux, je sais pas quel est le mieux. On est en C ici, pas en Lua. =)

Ou alors, si tu préfère rester dans le passage d'arguments, autant passer par une variable de type Color, au lieu d'un R, un G, et un B.
D'ailleurs, rendre cet argument non-obligatoire serait pas mal, et par exemple prendre la derniere couleur utilisée si celle-ci n'est pas précisée.

Passer un pointeur de color nécessite une allocation mémoire (en tout cas s'il utilise pas les macros). Des questions en plus ?
Non, sérieusement, si le passage par char est la fonction de base, il faut la laisser visible, tout le monde n'a pas envie d'utiliser les color.

[Lionel Debroux]

J'ai maintenant regardé les propositions d'API, et je réaffirme que 3 arguments séparés pour R, G, B n'est pas un design efficace: sur ARM, l'ABI veut que jusqu'à 4 arguments à une fonction, ils soient passés dans r0-r3, puis que les arguments au-delà de ces quatre-là soient passés sur la pile.
ExtGraph a été faite pour ne pas forcer les utilisateurs à s'enfermer dans un format de sprite donné, et à rester compatible avec les librairies de niveaux de gris qui n'utilisent pas deux plans consécutifs en mémoire même sur HW1 - mais du coup, certaines routines de sprite en niveaux de gris (*MASK*, par exemple) ont beaucoup d'arguments.

Soit on passe un seul argument "color" aux fonctions, soit on utilise le concept de "pen" (setColor globale, puis dessin d'une couleur donnée) - mais il faut vraiment éviter des APIs comme

Code: Tout sélectionner

void drawCharBckgRGB(short x, short y, char ch, char size, char R, char G, char B, char BW, char Rf, char Gb, char Bb, char BWb);

EDIT: ah, j'ai oublié de mentionner que je suis devenu un grand fan des types portables définis dans stdint.h: (u)int(8|16|32|64)_t. Je les ai ajoutés dans GCC4TI, leur absence était un des nombreux manquements aux standards hérités de TIGCC. En particulier, si tu veux vraiment faire des fonctions auxquelles on passe des arguments séparés pour R, G et B, mieux vaut utiliser "uint8_t" que "char" pour ces valeurs
Et je suggère de prévoir "uint16_t", plutôt que "char", pour l'argument caractère à dessiner de DrawChar: ça ne coûte à peu près rien, mais "uint8_t" limiterait la police à 256 symboles.