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

[Lionel Debroux]

Penses-tu que je doive traduire les commentaires de nRGBlib ?

Ca me paraît utile si tu veux des contributeurs

Dans mes débuts sur TI-68k, pour les programmes que je n'ai pas diffusés, j'ai certainement écrit des commentaires en français. Je pense en particulier à "mupzockv", avec lequel j'avais exploré l'utilisation de l'API d'AMS, de _rowread, et de handlers d'interruption / trap - difficile de le quitter si on ne connaît pas la combinaison de touches
Mais dans les programmes auxquels j'ai contribué des contributions plus ou moins importantes, ou les (moins nombreux) programmes que j'ai créés et diffusés, les commentaires sont en anglais.

[totorigolo]

Et une fois n'est pas coutume, c'est l'heure de la compilation propre J'avais linké les exemples à nRGBlib dans nspire-ld même. Mais si je veux faire quelque chose de propre, il faut linker depuis le Makefile... J'ai donc essayé ça :

Code: Select all

GCC = nspire-gcc
LD = nspire-ld
GCCFLAGS = -Os -Wall -W -marm
LDFLAGS = -static -L "../../../sdk/lib/" -lRGB
OBJCOPY := "$(shell (which arm-elf-objcopy arm-none-eabi-objcopy arm-linux-gnueabi-objcopy | head -1) 2>/dev/null)"
ifeq (${OBJCOPY},"")
   OBJCOPY := arm-none-eabi-objcopy
endif
OBJS = main.o snake.o pos.o
DISTDIR = ../bin
vpath %.tns $(DISTDIR)

all: CXSnake.tns

%.o: %.c
   $(GCC) $(GCCFLAGS) -c $<

%.o: %.S
   $(GCC) $(GCCFLAGS) -c $<

CXSnake.tns: $(OBJS)
   $(LD) $(LDFLAGS) $^ -o $(@:.tns=.elf)
   @mkdir -p $(DISTDIR)
   $(OBJCOPY) -O binary $(@:.tns=.elf) $(DISTDIR)/$@

clean:
   rm -f *.o *.elf
   rm -f $(DISTDIR)/CXSnake.tns


Et j'obtiens la sortie suivante :

Code: Select all

$ make
nspire-ld -static -L "../../../sdk/lib/" -lRGB main.o snake.o pos.o -o CXSnake.elf
main.o: In function `main':
main.c:(.text.startup+0xc): undefined reference to `clearScreen'
main.c:(.text.startup+0x34): undefined reference to `drawStr'
main.c:(.text.startup+0x9c): undefined reference to `clearScreen'
main.c:(.text.startup+0xb4): undefined reference to `drawStr'
snake.o: In function `Snake':
snake.c:(.text+0x6c): undefined reference to `clearScreen'
snake.c:(.text+0x84): undefined reference to `drawBox_'
snake.c:(.text+0xac): undefined reference to `drawStrBckg'
snake.c:(.text+0x130): undefined reference to `drawSquare_'
snake.c:(.text+0x190): undefined reference to `drawSquare_'
snake.c:(.text+0x1bc): undefined reference to `randMinMax'
snake.c:(.text+0x1d0): undefined reference to `randMinMax'
snake.c:(.text+0x1f4): undefined reference to `drawSquare_'
snake.c:(.text+0x4b8): undefined reference to `drawSquare_'
snake.c:(.text+0x52c): undefined reference to `drawStrBckg'
snake.c:(.text+0x550): undefined reference to `randMinMax'
snake.c:(.text+0x564): undefined reference to `randMinMax'
snake.c:(.text+0x5a4): undefined reference to `drawSquare_'
snake.c:(.text+0x5e4): undefined reference to `drawSquare_'
collect2: ld returned 1 exit status
make: *** [CXSnake.tns] Error 1

J'ai essayé toutes les combinaisons possibles (sauf une... la bonne), et rien ne fonctionne. Help ?

EDIT: Je me demande si c'est possible Aucun programme Ndless 2 n'utilise de bibliothèque statique...

[ExtendeD]

En mettant :

Code: Select all

$(LD) $(LDFLAGS) $^ -o $(@:.tns=.elf) -lRGB

c'est bon chez moi (tu peux garder ton -L dans LDFLAGS).

Quelques autres conseils pour avoir un build propre indépendant du SDK d'Ndless - tu ne veux pas que les builds de programmes utilisateurs cassent à chaque mise à jour du SDK d'Ndless (je devrais te faire un push BitBucket je suppose mais il est un peu tard pour apprendre sur le tas) :

- nRGBlib/Makefile : DISTDIR=../lib (et crée le dossier lib)
- samples/[chaque sample]/Makefile : -L "../../lib"
- Dans samples/[chaque sample]/Makefile : GCCFLAGS = -Os -nostdlib -I"../../include" (en arrêtant de copier les .h dans le SDK d'Ndless)
- Dans nRGBlib/Makefile : GCCFLAGS = -Os -nostdlib -I"../include"
- Dans tous les .c : Plus de chemin relatif vers tes .h avec ../.., mais <xxxx.h>
- include/charmap.h : transforme ça en .c pour ne plus avoir le warning GCC quand il n'est pas utilisé
- nRGBlib/Makefile : supprime : clear_cache.o idle.o: GCCFLAGS+=-marm
- Tu peux aussi supprimer tes inclusions de libndls.h, os.h te garantira toujours de l'inclure implicitement par convention d'Ndless.

Tu n'as donc plus de problème de linking avec libndls et contournement par copie ?

Sinon je vois sur ce PC avec un SDK fraîchement installé beaucoup d'erreurs de type "inline function 'fprintf' given attribute noinline [-Wattributes]". Toi aussi ? La dernière version de YAGARTO a dû modifier des choses...

[Lionel Debroux]

Les GCC et Clang les plus récents affichent pas mal de warnings en plus que les versions précédentes, et ça va continuer avec GCC 4.7 (au printemps) et Clang 3.1 (probablement plus tard, vu que 3.0 est sorti en novembre). Avec ceux-là, on pourra même utiliser un sous-ensemble du C11.

[totorigolo]

En mettant :

Code: Select all

$(LD) $(LDFLAGS) $^ -o $(@:.tns=.elf) -lRGB

c'est bon chez moi (tu peux garder ton -L dans LDFLAGS).

Yes !! Ca fonctionne Du coup, si je mets "-lndls", je n'ai plus aucun problème avec libndls, et plus besoin de copier le code.

Quelques autres conseils pour avoir un build propre indépendant du SDK d'Ndless - tu ne veux pas que les builds de programmes utilisateurs cassent à chaque mise à jour du SDK d'Ndless (je devrais te faire un push BitBucket je suppose mais il est un peu tard pour apprendre sur le tas).

J'ai appliqué tous tes conseils, sauf le "include/charmap.h => charmap.c" car le compilo me chante une douce "undifined reference to 'charmap'". Mais il ne s'agit que d'un warning

Sinon je vois sur ce PC avec un SDK fraîchement installé beaucoup d'erreurs de type "inline function 'fprintf' given attribute noinline [-Wattributes]". Toi aussi ? La dernière version de YAGARTO a dû modifier des choses...

Je t'avais déjà signalé ce problème par e-mail : pour chaque fichier.c incluant <os.h>, j'ai quelque chose du comme le code qui suit. Et ajouter "-Wattribute" ne change rien.

Code: Select all

nspire-gcc -Os -nostdlib -I"../include" -c setPixel.c
In file included from ../include/nCOMMON.h:4:0,
                 from setPixel.c:1:
c:/Users/Thomas/Programmation/TI-Nspire/Ndless/ndless-v3.1/sdk/bin/../include/os.h:254:1: warning: inline function 'printf' given attribute noinline [-Wattributes]
c:/Users/Thomas/Programmation/TI-Nspire/Ndless/ndless-v3.1/sdk/bin/../include/os.h:255:1: warning: inline function 'sprintf' given attribute noinline [-Wattributes]
c:/Users/Thomas/Programmation/TI-Nspire/Ndless/ndless-v3.1/sdk/bin/../include/os.h:256:1: warning: inline function 'fprintf' given attribute noinline [-Wattributes]
c:/Users/Thomas/Programmation/TI-Nspire/Ndless/ndless-v3.1/sdk/bin/../include/os.h:371:1: warning: inline function 'deflateInit2__swi' given attribute noinline[-Wattributes]

J'ai pushé les modifications sur Bitbucket.

EDIT: Non, mon ReadMe n'est pas inspiré de celui d'Ndless :-°

[totorigolo]

Je viens de finir mon Lisez-moi.txt et mon ReadMe.txt.

Pensez vous qu'il reste des choses à changer avant la release v0.2 ?

[Lionel Debroux]

Quand nous (les divers contributeurs) avons programmé ExtGraph, nous avons probablement créé trop de routines. Mais je pense vraiment que de ton côté, tu n'en fais pas assez
Côté face, tes drawTile sont génériques... mais côté pile, telles qu'elles sont écrites, elles vont être vraiment lentes pour le cas simple (nettement majoritaire, en pratique, sur TI-68k et d'autres plate-formes): dessin de sprites non scalés, i.e. size = 1.
C'est un cas particulier de l'utilisation trop étendue, à mon goût, de drawBox_, telle que ta lib est actuellement écrite

Une routine de sprite 16 bpp est facile: copie par blocs de 16 bits, en utilisant les modes postincrémentés de l'ISA ARM (un des trucs bien du 68000, repris sur l'ARM).
Une routine de sprites alignés 16 bpp peut utiliser des copies par blocs de 32 bits, si on force à 4 l'alignement de la source et de la destination.
Une routine de sprite 4 bpp peut être faite avec deux écritures 32 bits et un shift droit + un shift gauche par ligne.
Une routine de sprite alignés 4 bpp... est déjà faite dans la version Nspire de shuffle ( http://www.ticalc.org/archives/files/fi ... 43472.html )


Encore une fois, je ne dis pas ça pour t'embêter, mais parce que si je voulais programmer sur Nspire, pour des raisons d'efficacité vitesse et taille, je n'utiliserais pas ta librairie telle qu'elle est écrite (mais je pourrais y contribuer - enfin, si j'ai le temps: comme je l'ai dit à "le solutionneur" ailleurs, il n'est pas nécessairement bon que je m'implique dans un projet alors que je sais que j'aurai peu de temps)
Par exemple, je séparerais complètement le mode 4 bpp et le mode 16 bpp, je ferais des macros de pixel pour les utiliser notamment à la place de setPixel dans les fonctions (et ainsi optimiser davantage).

Certes, encore cet après-midi au boulot, je disais que quand il s'agit de programmer sur plate-forme embarquée, je suis drogué à la performance
Mais c'est là que c'est le plus important

[totorigolo]

nRGBlib v0.2 :

Je viens de releaser à l'instant nRGBlib v0.2. Elle a atteint ses objectifs qui étaient :

• Compiler en statique pour pouvoir l'utiliser comme libndls.
• Organiser la biblio pour permettre une expansion propre dans la continuité.
• Compatibilité avec Nspire classiques et CX.
• Réduire le nombre d'arguments des fonctions, afin d'accélérer l'exécution -> uniquement les couleurs pour cette version.
• Version prête pour la sortie Ndless 3.

Cette version n'avait donc pas pour but d'ajouter de nouveautés, à part un nouvel exemple. J'ai donc, en releasant cette version, retiré mon verrou créatif (et destructeur ) .

Cette version est téléchargeable sur son dépot Mercurial :

• https://bitbucket.org/totorigolo/nrgblib : Page d'accueil
• https://bitbucket.org/totorigolo/nrgblib/downloads : Page de téléchargement

-------------------------------------------------------------------------------------------------------------------------------------

Lionel :
Cette version n'apporte aucune nouveauté côté fonctions, c'était son but. Elle devait juste résoudre quelques problèmes et être organisée pour la sortie de Ndless 3.

Ensuite, nRGBlib n'est peut-être pas autant optimisée qu'elle pourrait l'être, mais je suis incapable de créer quelque chose de mieux pour le moment. Je n'ai pas les connaissances nécessaires pour cela : je ne suis pas (encore) programmeur comme toi . J'ai 15 ans et j'ai lu il y a 4 ans les tutoriels du Site du Zéro (C/C++ concernant nRGBlib), ces tutoriels sont je pense une bonne base pour commencer, mais n'approfondissent pas tellement. J'en ai appris autant ici grâce à toi que sur le SdZ .
A vrai dire, je n'ai pas compris grand chose à propos des routines de sprites que tu as expliqué dans ton post précédent, ni dans le code de shuffle, mais je vais rechercher sur le Web

Et puis mon but avec nRGBlib, ce n'est pas tellement d'être une bombe de vitesse, ça s’améliorera (j'espère) au cours du temps, c'est surtout de fournir une base rapide pour ceux qui ne veulent pas s'embêter à créer des routines d'affichage.

Enfin, j'ai un scoop : j'ai commencé à créer un système d'images. Je suis actuellement en train de rechercher une bonne méthode de stockage

[totorigolo]

Je suis actuellement en train d'ajouter plein de nouveautés à nRGBlib, dont les images. Le système est actuellement fonctionnel, mais je n'ai optimisé pour le moment que les CX (16bpp), car je tient absolument à garder une compatibilité entre 16bpp / 4bpp sans recompilation, et je galère un peu avec les pointeur void*...

Donc si quelqu'un veut m'aider dans l'optimisation des 4bpp, afin d’accélérer la sortie de la prochaine version de nRGBlib

Je prévois aussi l'ouverture des PNG et JPG (car pour l'instant le format est un que j'ai créé) en intégrant le code source de mViewer pour les BMP et PNG et de Nspire Movie Player (de tangrs) pour les JPG, qui sont sous licence GPL v2 et v3.

[totorigolo]

Voici un exemple des fonctionnalités de nRGBlib pour le moment.

L'éditeur de carte est codé en C++ avec la SFML. Le tout a été créé en suivant de près ou de lien ce tuto.


L'exemple tourne moins vite sur 4bpp à cause de non-optimisation.