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

[Levak]

Face à ces arguments, c'est ptet finalement préférable de faire un setColor(), tout en donnant la possibilité (surcharge) de gérer une couleur par un *color

[totorigolo]

Tout d'abord, je me dois de le dire, et je m'excuse : je ne porte pas la SDL. Pour le moment, j'essaie de terminer la version 0.2 de nRGBlib, puis je me pencherai plus sérieusement vers la SDL, voir si c'est à mon niveau. Cela dit, la SDL ne propose pas tant de choses que ça niveau rendu, étant à l'origine créée dans le but d'avoir une fenêtre de rendu OpenGL sous Windows, il me semble. Elle propose il me semble uniquement l'affichage de rectangles et de lignes, après c'est les add-on qui sont intéréssantes... (cf: http://wiki.libsdl.org/moin.cgi/APIByCategory).

Alors, pour le problème, deux choix s'offrent à moi : la couleur globale en mode crayon ou les fonctions qui prennent la couleur, mais avec peu d'arguments (je penses avoir trouvé un moyen de faire court ). Le problème avec mon moyen de faire court : la couleurs est en 16 bits, soit 2 octets. Si on veut permettre de choisir la couleur pour Nspire non-couleur, ça nous donnerais une couleur de 20 bits, soit... 2 octets et demi, donc trois. Ensuite, le type le plus proche est le int -> 4 octets. J'ai vu les bit fields qui servent apparament à optimiser ça, mais je sais pas comment ça marche.

Est-ce que cela vous va ?
.H

Code: Select all

#define RGB(r, g, b, bn) ((bn << 15) | (r << 11) | (g << 5) | b)
#define LINE(x1, y1, x2, y2) ((x1 << 25) | (y1 << 17) | (x2 << 8) | (y2))
#define SQUARE(x, y, c) ((x << 16) | (y << 8) | (c))

typedef unsigned int Color; // 20 bits -> 3 octets -> unsigned int (4 octets)
typedef unsigned long long Line; // 34 bits -> 5 octets -> unsigned long long (8 octets)
typedef unsigned int Square; // 25 bits -> 4 octets -> unsigned int (4 octets)

/// Dessine un pixel en couleur
void setPixel(short x, short y, Color);

/// Dessine une ligne quelconque en couleurs
inline void drawLine(Line *l, Color col);

/// Dessine un carré en couleur
inline void drawSquare(Square *s, Color col);

.C

Code: Select all

// Un p'tit exemple
SetPixel(20, 30, RGB(255, 128, 0, 5));
drawSquare(SQUARE(50, 60, 30), RGB(0, 255, 255, 6));
Color colApple = RGB(255, 0, 0, 5);
drawSquare(SQUARE(50, 60, 30), colApple);

// Style Lua (on rajoute le ", c")
Color c = RGB(255, 0, 0, 5);
drawSquare(SQUARE(0, 0, 5), c);
drawSquare(SQUARE(30, 0, 20), c);
drawSquare(SQUARE(20, 30, 40), c);
c = RGB(0, 255, 0);
drawLine(LINE(5, 6, 25, 26), c);

Le code a été écrit de tête, pas testé.

PS : J'espère n'avoir oublié aucun de vos conseils

[Lionel Debroux]

Tout d'abord: je ne veux pas te décourager par mes remarques, c'est bien d'avoir de (relatifs) nouveaux venus qui ont des idées et de la motivation

Si on veut permettre de choisir la couleur pour Nspire non-couleur, ça nous donnerais une couleur de 20 bits, soit... 2 octets et demi, donc trois.

Je ne pense pas qu'il faille essayer de gérer les Clickpad & Touchpad d'un côté, et les CX & CM de l'autre, avec les mêmes fonctions: c'est beaucoup plus lourd
Sur TI-68k, je n'ai jamais été un grand fan de la compatibilité on-calc entre 89/89T et 92+/V200, qui pouvait facilement coûter au moins 10 KB sur des programmes comme TI-Chess; et ces modèles n'avaient pourtant pas une différence aussi importante que les bpps de l'écran, qui changent tous les graphismes.

Ensuite, le type le plus proche est le int -> 4 octets.

uint32_t
Il est des plate-formes, dont les TI-68k tournant AMS et compatibles, où sizeof(int) != 4.


Remarques sur les exemples de code.
* L'utilisation de "unsigned long long" (c'est plus portable et plus court d'écrire uint64_t ), pour essayer de compresser des valeurs, est à proscrire car elle coûte cher En interne, le compilo a recours à des fonctions spéciales de la libc pour manipuler de telles valeurs (à moins que les versions les plus récentes de GCC soient capables d'émettre des shifts inline ?), et en ASM, passer les arguments à une telle fonction serait désagréable.
* j'imagine que c'est un reste de copier-coller, mais si on garde ta façon de compresser les paramètres (???), drawLine et drawSquare doivent prendre une valeur comme premier argument, et non un pointeur
* dans les exemples, tu passes des valeurs 8 bits à RGB, alors que ta définition de macro ne peut pas avaler de telles valeurs. Regarde la page précédente ma version qui serait capable de le faire (si je ne me suis pas planté sur les shifts ).
* les bit fields dans une struct s'utilisent simplement, en fait
Et sur l'ISA ARM, les bit fields sont moins inintéressants que sur d'autres ISA car les shifts / rotates sont très développés.
Pour permettre un accès aux composantes séparées, aussi bien qu'un accès à la valeur brute, RGB pourrait être défini de la façon suivante (mais attention à l'endianness !):

Code: Select all

union RGB {
    struct components {
        int r : 5; // peu importe le type de r, g, b: le ": x" définit un bit field.
        int g : 6;
        int b : 5;
    };
    uint16_t raw;
}

Naturellement, avec une telle définition, des écritures aux composantes r, g et b ne pourraient fonctionner que si les valeurs sont entre 0 et 31 (5 bits), ou 0 et 63 (6 bits). Hors de ces plages, je ne sais même pas si le standard C définit le comportement du code (= ça risque fort de faire des conneries)

[Levak]

Tout d'abord, je me dois de le dire, et je m'excuse : je ne porte pas la SDL. Pour le moment, j'essaie de terminer la version 0.2 de nRGBlib, puis je me pencherai plus sérieusement vers la SDL, voir si c'est à mon niveau. Cela dit, la SDL ne propose pas tant de choses que ça niveau rendu, étant à l'origine créée dans le but d'avoir une fenêtre de rendu OpenGL sous Windows, il me semble. Elle propose il me semble uniquement l'affichage de rectangles et de lignes, après c'est les add-on qui sont intéréssantes... (cf: http://wiki.libsdl.org/moin.cgi/APIByCategory).

Aaah, pas de problème, j'ai mal lu c'est tout

Alors, pour le problème, deux choix s'offrent à moi : la couleur globale en mode crayon ou les fonctions qui prennent la couleur, mais avec peu d'arguments (je penses avoir trouvé un moyen de faire court ). Le problème avec mon moyen de faire court : la couleurs est en 16 bits, soit 2 octets. Si on veut permettre de choisir la couleur pour Nspire non-couleur, ça nous donnerais une couleur de 20 bits, soit... 2 octets et demi, donc trois. Ensuite, le type le plus proche est le int -> 4 octets. J'ai vu les bit fields qui servent apparament à optimiser ça, mais je sais pas comment ça marche.

J'ai dû encore mal lire, mais je comprends pas pourquoi tu ne transformes pas ta couleur en niveau de gris à l'affichage dans la fonction setPixel() ? Je veux dire, tu utiliserais partout des couleurs, comme pour ce que TI a fait pour le Lua. A part un pseudo temps de conversion pour les Clickpads (qui sont d'ailleurs en peu plus rapide que les CX ça tombe bien ) je ne vois rien qui puisse t'arrêter dans ton choix.

[totorigolo]

Je voulais pouvoir donner le choix à l'utilisateur de choisir la couleur pour CX et non-CX, comme ExtendeD me l'avais aussi suggéré. Mais après c'est comme vous voulez, moi je n'ai qu'une CX donc je m'en moque :

[Lionel Debroux]

La conversion RGB 5:6:5 bits -> grayscale 4 bits est plus difficile que les conversions RGB 5:6:5 <-> 8:8:8, en taille de code et en temps d'exécution
Et je ne me souviens pas que l'écran grayscale des Clickpad & Touchpad gère correctement 16 bpp (profondeur que le contrôleur LCD sait gérer), mais peut-être que je me trompe.

[Laurae]

Et je ne me souviens pas que l'écran grayscale des Clickpad & Touchpad gère correctement 16 bpp (profondeur que le contrôleur LCD sait gérer), mais peut-être que je me trompe.

Il y a 16 niveaux de gris sur l'écran des sans couleurs

[Lionel Debroux]

Par défaut, en effet.
Mais l'énorme daube d'écran dont sont équipées les Clickpad et Touchpad peut pourtant être drivé en 8 bpp, c'est par exemple ce que nDOOM fait... peut-être qu'il peut être drivé en 16 bpp (peut-être au prix d'une plus grande lenteur encore ?) ?

[ExtendeD]

Pas bête, a tester. totorigolo tu peux aussi demander à calc84maniac qui s'y connait pas mal sur le fonctionnement des ecrans.

[totorigolo]

Est-ce que ce code est censé fonctionner en C ? (code pondu tout frais, sans copié-collé ni test donc possible erreur de syntaxe)

Code: Select all

#define newRGB(r, g, b) (Color) (uint16_t) (((r / 8) << 11) | ((g / 4) << 5) | (b / 8))
#define RGB(r, g, b) (Color*) (uint16_t) (((r / 8) << 11) | ((g / 4) << 5) | (b / 8))

void setPixel(short x, short y, Color *c)
{
    /* ... */
    bar = c->raw;
}
void drawBox(short x, short y, Color *c)
{
    /* ... */
    setPixel(x, y, c); // Fonctionne pas ici (voir plus bas)
}

int main()
{
    Color cc = newRGB(123, 125, 174);

    drawBox(0, 40, &cc); // Fonctionne
    drawBox(0, 0, RGB(137, 255, 137)); // Fonctionne pas (voir plus haut)

    return 0;
}

Ça ne marche pas surement à cause du pointeur temporaire, mais existe-t-il un autre moyen ? Ou est-ce que le pointeur est utile ?

PS: Nouveau dépot Mercurial (volontairement pas en première page / présentation) : https://bitbucket.org/totorigolo/nrgblib/overview