Forum TI-Planet.org

Bonjour à tous,

Je vais poster ici l'avancement de mon projet, nRGBlib.
News correspondantes:

• v0.1 : http://tiplanet.org/forum/viewtopic.php?t=8591
• v0.2 : http://tiplanet.org/forum/viewtopic.php?t=8672
• v0.3 : http://tiplanet.org/forum/viewtopic.php?p=123024

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

Feuille de route :

nRGBlib 0.1 : Ancienne version stable - accessible sur demande

• Dessin de pixel en couleurs.
• Effacage de l'écran en couleurs.
• Dessin de ligne quelconque (à n'importe quelle inclinaison) en couleurs.
• Dessin de rectangle / carré (et aussi lignes verticales et horizontales) en couleurs.
• Dessin de cercle en couleurs.
• Dessin de disque en couleurs.
• Dessin de triangle (uniquement les contours) en couleurs.
• Dessin de tile (définition à lire car très bon tuto) de 8 pixels de côté avec redimensionnement (les tiles de n'importe quelle taille sont prévus pour nRGBlib v0.2) en mode unicolore et multicolore.
• Dessin de lettre, avec possibilité de redimensionner (uniquement x2, x4,... pour la version 0.1) en couleurs.
• Dessin de texte, possibilité de redimensionner et de retourner à la ligne en couleurs.

nRGBlib 0.2 : Ancienne version stable - publique

• 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.
• Ajout de la licence MPL 2.0.
• Version prête pour la sortie Ndless 3.

nRGBlib 0.3 : Dernière version stable - publique

• Support des images. Le format des images est un format perso. Cependant, un exporter est fourni et est capable d'exporter les formats les formats les plus utilisés (bmp, dds, jpg, png, tga, psd (merci la SFML ) ).
  La taille de ces images est plus petite que le BMP, mais plus grosse que le PNG : image de 320x240 => BMP = 225Ko, PNG = 6.19Ko et PERSO = 151Ko.
  Les images sont externes au programme, contrairement aux tiles.
  Actuellement, les 4bpp ne peuvent pas afficher des images à largeur impaire, ainsi 240x245 est mauvais → 240x244.
• Support des sous-images, c'est-à-dire l'affichage d'une partie d'une image.
• Gestion du buffering. Possibilité d'utiliser plusieurs écrans ou de faire une capture d'écran (mais pas de l'enregistrer).
• Boost de la fonction drawBox(), elle-même utilisée par plusieurs autres. L'ancienne version, plus lente, est encore disponible : drawBoxSl().

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

Fonctionnalités :

La nRGBlib est organisée en plusieurs modules. En plus de la compilation statique, cela permet de n'utiliser que les modules utiles au projet à développer, et de ne pas alourdir inutilement l'exécutable. Pour le moment, nRGBlib s'organise ainsi :

• nCOMMON:
  
  • Couleur, conversion RGB <-> BW, couleurs prédéfinies.
  • Buffer écran, création, affichage, capture d'écran, vidage.
  • setPixel(), clearScreen().
• nGEO:
  
  • Formes: Disque, Cercle, Ligne, Rectangle, Carré, Triangle.
  • Fonctions d'affichage de ces formes.
• nTILE:
  
  • Tile 8x8 en une couleurs ou plusieurs couleurs.
  • Fonctions d'affichage des tiles.
  • → Les tiles sont compilées AVEC le programme.
• nIMAGE:
  
  • Image, création, chargement, affichage, getPixel().
  • Sous-image, création, chargement, affichage, getPixel().
  • → Les images sont enregistrées EN-DEHORS du programme.
• nGUI:
  
  • Structures : Lettre, Texte.
  • Fonctions d'affichage de ces structures.
• nMATHS:
  
  • Fonctions rand() + randMinMax().

Légende :
Vert = Fait
Violet = A débugger / A revoir
Orange = En cours
Rouge = A faire

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

Médias :
GeometriCX v0.1


nRGBlib v0.1 avec CXSnake et GeometriCX


nRGBlib v0.2dev avec HelloRGB, CXSnake et GeometriCX (Merci à Goplat pour son émulateur)


nRGBlib v0.3 indev : éditeur de map + RPG

L'affichage sur 4bpp a été beaucoup accéléré dans la version 0.3, mais la vidéo a été prise avant l'optimisation.

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

Téléchargements :

Lien vers le dépôt BitBucket qui sera toujours à jour.
https://bitbucket.org/totorigolo/nrgblib/downloads

• Tags → v0.* → zip pour obtenir la source.
• "samples-v0.*.zip" pour obtenir uniquement les exécutables des exemples.

------------------------------------------------------------------------------------------
Si vous avez des questions ou des suggestions par rapport à cette bibliothèque, n'hésitez pas.

Bien

Regarder du côté de GCC4TI ou SDL pour s'inspirer des fonctionnalités.

En tant que tel, GCC4TI n'offre presque rien pour les graphismes, même s'il en offre plus (SPRT_RPLC, ClipSprite*) que TIGCC.

Mais comme nous l'avons écrit, en fin de compte, ExtendeD et moi pensons davantage à un portage de SDL qu'à une librairie inspirée de SDL
C'est vraisemblablement plus utile à la communauté de porter une librairie assez largement utilisée, et portable (assez bonne couche d'abstraction matériel), comme SDL, que de faire du nouveau code s'en inspirant (ou pire, s'inspirant d'ExtGraph, Genlib, hpgl, et autres, moins largement utilisés).
Quand j'avais posté http://www.unitedti.org/forum/index.php?showtopic=9384 il y a un an et demi, je n'avais pas encore pensé à SDL.

Compiler en statique pour pouvoir l'utiliser comme libndls.

Oui, ça peut être utile.
Ceci étant dit, comme sur TI-68k (ça me rappelle de looongs flames ), utiliser des libs dynamiques a au moins deux avantages:
1) possible gain de place si la lib est assez petite / s'il y a suffisamment de programmes clients (à cause des recopies évitées);
2) ce serait une bonne occasion de faire avancer, là encore au bénéfice de la communauté dans son ensemble, le loader ELF de tangrs (ou un loader BFLT, ce format étant beaucoup plus simple)
Bien sûr, SDL supporte déjà, pour autant que je sache, les deux modes.


Bon, après, il ne faut pas non plus oublier le plaisir de développer, et l'apprentissage
Faire les fonctions par toi-même (ce que tu as déjà commencé à faire, du reste) sera plus enrichissant pour toi que de porter une lib existante, bien sûr. Mais moins utile, vraisemblablement, à long terme, pour la communauté.

Merci pour tes conseils

Bon, après, il ne faut pas non plus oublier le plaisir de développer, et l'apprentissage

L'apprentissage, c'est clairement ce qui me limite et ce qui me motive. Un portage d'une bibliothèque, je n'ai aucune idée de comment faire. Et à vrai dire, tous les jours m'apprennent des truc nouveaux côté programmation. Avec un niveau SdZ depuis 3 ans et une bonne passion informatique, on arrive à faire des choses, mais c'est pas toujours facile.
Mais c'est clairement pour la communauté TI que je fais ça, et vu que tout est bon pour l'apprentissage, je vais suivre tes conseils.

Donc si quelqu'un (tu) peut me guider pour porter la SDL : un tuto, un post détaillé d'un porteur,...

Lionel Debroux wrote:

Compiler en statique pour pouvoir l'utiliser comme libndls.

Oui, ça peut être utile.
Ceci étant dit, comme sur TI-68k (ça me rappelle de looongs flames ), utiliser des libs dynamiques a au moins deux avantages:
1) possible gain de place si la lib est assez petite / s'il y a suffisamment de programmes clients (à cause des recopies évitées);
2) ce serait une bonne occasion de faire avancer, là encore au bénéfice de la communauté dans son ensemble, le loader ELF de tangrs (ou un loader BFLT, ce format étant beaucoup plus simple)
Bien sûr, SDL supporte déjà, pour autant que je sache, les deux modes.

En attendant de compiler en dynamique avec le loader de tangrs (que je vais suivre de près, ainsi que son compilo C++ pour Nspire), je voudrais déjà réussir à compiler en statique... Mais je n'y arrive pas. Je bloque au moment où il faut ajouter "-lnRGBlib" à nspire-ld.
J'obtient l'horreur suivante :

Code: Select all

$ make
make all in CXSnake...
make[1]: Entering directory `/c/Users/moaa/Programmation/TI-Nspire/Ndless/nRGB
lib/src/samples/CXSnake'
nspire-ld -lRGB main.o snake.o pos.o -o snake.elf
c:/program files (x86)/yagarto/bin/../lib/gcc/arm-none-eabi/4.6.2/../../../../ar
m-none-eabi/bin/ld.exe: cannot find -lRGB
collect2: ld returned 1 exit status
make[1]: *** [snake.tns] Error 1
make[1]: Leaving directory `/c/Users/moaa/Programmation/TI-Nspire/Ndless/nRGBl
ib/src/samples/CXSnake'
make: *** [all] Error 1

SDL a été porté sur suffisamment de plate-formes différentes, et d'OS différents, pour que le portage vers une nouvelle plate-forme en soit raisonnablement facile. Sinon, les gens n'utiliseraient pas ça
Il n'est pas nécessaire de porter tout SDL d'un coup, puisque la librairie est divisée en plusieurs morceaux. Par exemple, il est envisageable de commencer par le portage du système vidéo (et encore, pas forcément tout), dans un premier temps.
Et il y a des surcouches à SDL qui peuvent comporter des fonctions intéressantes pour nous.

* les sources de SDL contiennent un README.Porting
* dans la version Mercurial (qui deviendra SDL 1.3), je vois des plate-formes Pandora ( http://openpandora.org/ ) et Wiz ( http://fr.wikipedia.org/wiki/GP2X_Wiz ). Ce sont deux exemples de plate-formes ARM pour lesquelles des portages ont été faits (mais il y a des accélérateurs graphiques que nous n'avons pas).


A l'utilisation, la lib SDL est bien sûr moins simple qu'une lib comme nRGBlib, plus focalisée sur une seule plate-forme. Mais SDL est une meilleure introduction à la programmation graphique moderne - comme le Lua propriétaire de TI, d'ailleurs: son API événementielle non portable a au moins ce mérite-là, même si elle complique le portage depuis et vers d'autres plate-formes.



Quant à la compilation en statique: ce que tu veux, c'est créer une archive de fonctions. Donc, utiliser ar (arm-none-arbi-ar).

totorigolo :
- Utiliser l'option -L "chemin/vers/dossier/contenant/fichier/a"
- Ta lib doit s'appeler libRGB.a si tu utilises l'option -lRGB

Lionel ("Et il y a des surcouches à SDL qui peuvent comporter des fonctions intéressantes pour nous.") : Effectivement, je voyais ça aussi : http://www.libsdl.org/libraries.php

ExtendeD: J'ai réussi, j'ai rajouté "-lnrgb" à la fin de nspire-ld

Lionel: J'avais pas vu le README.Porting. Je me plonge de ce pas dans cet océan de fichiers

Lionel Debroux wrote:SDL a été porté sur suffisamment de plate-formes différentes, et d'OS différents, pour que le portage vers une nouvelle plate-forme en soit raisonnablement facile. Sinon, les gens n'utiliseraient pas ça

Effectivement, la SDL a été portée vers beaucoup de plateformes, selon le README.Platforms :

README.Platforms wrote:This is a list of the platforms SDL supports, and who maintains them.

Officially supported platforms
==============================
(code compiles, and thoroughly tested for release)
==============================
Windows XP
Windows Vista
Windows 7
Mac OS X 10.4+
Linux 2.6+
iOS 3.1.3+
Android 1.6+

Unofficially supported platforms
================================
(code compiles, but not thoroughly tested)
================================
Windows CE
FreeBSD
NetBSD
OpenBSD
Solaris

Platforms supported by volunteers
=================================
Pandora - maintained by Scott Smith <pickle136@sbcglobal.net>

Platforms that need maintainers
===============================
Nintendo DS
Haiku

Mais ce qui me pose soucis pour le moment, c'est que n'ayant jamais utilisé la SDL (trouvant la SFML meilleure en C++), je ne connais pas du tout les différents modules. En plus de cela, je n'ai aucune idée de comment faire pour la porter, les explications se limitant à un README.Porting très sommaire. Je ne connais rien également aux Makefile...
J'essaie donc pour le moment de comprendre comment la version DS et la version Pandora fonctionnent, et par où commencer, et quel est le code minimal pour réussir à compiler avec nspire-gcc.

Moi non plus, je n'ai jamais utilisé la famille de libs SDL, et README.Porting est en effet sommaire

Je pense que les fonctions de base seront celles qui définissent les surfaces de travail (SDL_Surface et fonctions associées) et le dessin de pixels.

C'est trop bon de virer les quelques 4.048 fichiers inutiles au portage de la SDL . Bien sûr, j'en rajouterai d'autres, et j'en ai enlevé certains que je remettrai après. Il y a aussi l'audio, peut-être qu'un jour il sera utile... si quelqu'un crée un système simple et fiable pour se brancher sur les pins du dock et avoir le son (ça a déjà été fait pas Levak il me semble ici).