Boo v3.1 - Page 3

./55 pourquoi c'est aussi moche? Même le logo de yaronet a plus de résolution. la qualité est importante pour promouvoir ndless, tous les boo précédents étaient en haute résolution.

@Lionel : Yep je vais changer pour les stdint.h.
Le GetPixel (pas encore codé)est un copié collé su setPixel.
Pour l'instant mes draw sprites sont tout pourris, aucunes optimisations (pour des 8x8 / 16x16 / 32x32).

J'ai regardé un peu le SDK de Mr Mirko, et sur gp32x y a des fonctions de sprites avec de lasm pour booster le truc...mais pour l'instant je suis trop rouillé pour faire joujou avec ce genre de choses.

@Folco : Ouais ce serais mieux c'est certain, mais je pense que j'aurais pas le temps, ni l'envie d'aller aussi loin. La je fais un peu joujou par nostalgie.

@squalyl : ouais je sais, c'est un 75 x 75 que j'ai agrandis, j'ai pas trouvé mieux (on me la filé sur le channel IRC de tiplanet). Si jamais je suis preneur d'un 320x240

c'est un facteur exactement x2 là ton affichage? si c'est le cas j'ai rien à dire, sauf essayer de l'afficher sans agrandir

c'est ptet la capture d'écran qui est pourrite

C'est pas x2 exact....je vais essayé de trouver mieux

fais x2 exact l'apparence devrait s'améliorer

le boo officiel en haut de cette page fait 75x75, sinon faut demander l'original à yaro

squalyl (./65) :
sinon faut demander l'original à yaro

pisse très très fort en l'air, à mon avis il y a plus de chances d'obtenir l'original comme ça

./60 rien n'empeche de "preconvertir" avant utilisation les sprite en gray suivant le hw, mais bien sur une ecriture en 8b ou 16b serais plus lourde dans la majorité des cas que le 4b (mais aussi bien plus simple à réaliser)

de plus se serais compatible entre les modèles de calc sans faire galérer les dev avec deux versions du code et des gfx

Lionel Debroux (./60) :
La conversion R5G6B5 -> G4 coûte cher.

Bôaf...
[code]uint8_t RGB555_to_Gray4[65536];[/code]

Lionel Debroux (./60) :
les possesseurs de Clickpad / Touchpad vont vite se trouver ostracisés, à cause de l'écran à pleurer

Si l'écran n'était pas pourri, ça ne serait pas une TI™

Ouais, mais alors, la CX, dont l'écran est bien meilleur, n'est pas une TI

r043v (./39) :
tout dépend de ce que tu appelles "correcte" à 33mhz je jouais surtout à mario1, tennis color et les zelda, et c'était parfaitement jouable

Le faire à 33 MHz c'est carrément gore de mon expérience, mais pourquoi pas, si tu le dis.

Folco (./48) :
Oh, je me doute bien qu'il y a pire dans certains softs, oui, je me demande juste comment on fait pour s'y retrouver...

Avec un IDE correct ce n'est pas un problème, p.ex. Navigator dans NetBeans, Show Document Items dans XCode. Ca liste les fonctions du fichier source, on peut facilement rechercher dedans, sous XCode on peut ajouter des marqueurs dans le code (// MARK: blablabla) pour segmenter la liste, sous NetBeans on peut auto-réduire des parties de code et les développer au besoin en ajoutant un marqueur dans un commentaire, etc.

../68

0² est un spécialiste ! #sisi#

Zerosquare (./68) :

Lionel Debroux (./60) :
La conversion R5G6B5 -> G4 coûte cher.

Bôaf...
[code]uint8_t RGB555_to_Gray4[65536];[/code]

Ou:

u8 rgb565_to_gray4(u16 rgb_color) {
    return rgb_color >> 12;
}

Pour peu qu'on aime le rouge ça fera très bien l'affaire ^^

Zerosquare (./68) :
uint8_t RGB555_to_Gray4[65536];

Bourrin

Il vaux mieux le faire sur le vert alors

rgc565_to_gray4:
   lsr     r0, r0, #5
   and     r0, r0, #63	
   bx      lr

Folco (./74) :

Zerosquare (./68) :
uint8_t RGB555_to_Gray4[65536];

Bourrin

Extrait de code de 0²:

uint8_t Floyd_TabNBR[256];
uint8_t Floyd_TabNBG[256];
[...]
void Floyd_Init(uint32_t larg, uint32_t haut)
{
[...]
      uint8_t *p1 = Floyd_TabNBR;
      uint8_t *p2 = Floyd_TabNBG;
[...]
      for (n = 0; n < 256; n++)
      {
         *p1++ = (uint8_t)((n * 66) >> 8);
         *p2++ = (uint8_t)((n * 160) >> 8);
[...]

Hey ! Je ne t'ai pas donné l'autorisation de diffuser mon code sous ZPL !

( )

Vu l'extrait, ça limite les possibilitée de copie

Je connais aussi http://alienryderflex.com/hsp.html . Bon, évidemment, avec les coefficients flottants, c'est inenvisageable pour de l'embarqué
Mais une formule du genre sqrt( .250 R^2 + .625 G^2 + .125 B^2 ) ferait une approximation rapide entre sqrt( .241 R2 + .691 G2 + .068 B2 ) et sqrt( .299 R2 + .587 G2 + .114 B2 ). Ca fait longtemps qu'il y a des routines de sqrt rapides pour 16 bits.

pourquoi in-envisageable ? il y à beau avoir des division et flottant rien n’empêche son utilisation, et même si ta 10000 sprites à parser pour changer les couleurs, suffit de le faire une seule fois

après la solution de 0² de faire une grosse table est surement le mieux :- )

et rien n’empêche de générer la table avec cet algo non plus

./78: je ne suis pas vraiment convaincu par ses images de démo, a pars la palette (je testerais pour voir ce que ça donne) les autres ne sont pas transcendant du tout..

Je ne sais pas trop à quoi il joue, la formule pour déterminer la luminosité équivalente est connue et très utilisée : http://en.wikipedia.org/wiki/YUV#Conversion_to.2Ffrom_RGB (ici c'est la composante Y')

Seul point qui pose problème : beaucoup de softs semblent appliquer la formule aux valeurs RGB telles quelles, alors qu'il faut d'abord les linéariser (c'est-à-dire annuler l'effet du gamma de l'image d'entrée), puis appliquer le gamma qui correspond au moniteur sur lequel on va afficher le résultat.
(c'est peut être ça qu'il prend pour un carré et une racine carrée, d'ailleurs)

Idéalement il faudrait mesurer la fonction de transfert de l'écran de la nSpire pour ça.

Toujours est-il que c'est justement là que les tables précalcs prennent toute leur utilité

Je viens de regarder les images de démo sur un meilleur écran que tout a l'heure, et meme la je trouve pas son approche transcendante...

tangrs, déjà auteur de nombreux travaux et programmes fort intéressants pour la Nspire (entre autres: compilation de C++ avec Ndless, effet rétro à l'extinction de la machine, Nspire Movie Player, prototype de multi-threading, horloge), continue à travailler sur le chargement de programmes

Les lecteurs se demanderont peut-être pourquoi il est utile d'avoir ce genre de chargeurs. La réponse est simple: pour pouvoir bénéficier d'une facilité de programmation plus proche de ce qui se fait sur la plupart des environnements de programmation, dont les TI-68k d'ailleurs - par exemple, les variables globales relogées
L'absence de relocation automatique nécessite de faire ces relocations à la main, ce qui complique singulièrement la réalisation des gros programmes. Ndless fournit nl_relocdata, mais c'est fastidieux à utiliser, et peut être difficile.


Bref, un petit peu d'historique des loaders de tangrs:
* il y a des mois, tangrs avait fait ndless-elfloader, prototype de chargeur ELF, c'est à dire le format extensible et portable de fichiers objet et binaires, utilisé sur Linux depuis des années. C'était assez compliqué et lourd, et certains fichiers à charger étaient très gros alors qu'ils ne contenaient que très peu de code. Voir http://www.omnimaga.org/index.php?topic=11904.0 pour plus de détails.
* le 31 mars, il a fait un chargeur ajouté au programme par un outil côté ordinateur, qui a pour but de reloger le programme avant de déclencher son exécution, ndless-standalone-relocator: http://www.omnimaga.org/index.php?topic=13117.0 . Et au cours de cette dernière discussion, "bFLT" a de nouveau été mentionné.
bFLT est un format beaucoup plus simple qu'ELF, il peut facilement être obtenu à partir de fichiers ELF et facilement chargé, mais il est suffisant pour résoudre les plus gros problèmes de relocation que nous rencontrons actuellement. De plus, il est utilisable pour gérer des librairies dynamiques et des binaires compressés (le loader bLFT du kernel Linux sait faire).

* tangrs s'est donc vraiment intéressé à bFLT... et quelques heures plus tard, le nouveau prototype ndless-bflt-loader est né, avec sa documentation développeur pour ajouter le convertisseur ELF -> bFLT à l'environnement de développement et changer les Makefiles
Il l'a annoncé dans le même topic que ndless-standalone-relocator: http://www.omnimaga.org/index.php?topic=13117.msg240684#msg240684 .
Puis un topic a été créé: Ndless bFLT loader .


Aujourd'hui 3 avril, tangrs considère ndless-bflt-loader comme prêt à l'emploi, et intégrable dans Ndless
Une telle intégration devrait accélérer l'adoption de bFLT, par nSDL par exemple.

très beau!

Superbe boulot. Mais un soft de relogement intégré, c'est en fait un code de démarrage façon nostub ? Et ce qu'il fait, c'est intégrer ça à Ndless ? Il ne peut y avoir de tsr pour faire ça sur Nspire, reloger les programmes ?

Mais un soft de relogement intégré, c'est en fait un code de démarrage façon nostub ?

ndless-standalone-loader est en effet un code de démarrage façon AMS native.

Et ce qu'il fait, c'est intégrer ça à Ndless ?

Oui, modifier Ndless pour y intégrer ndless-bflt-loader

Il ne peut y avoir de tsr pour faire ça sur Nspire, reloger les programmes ?

Ndless 3.1 supporte mainenant les TSR (fixprint en est un, par exemple), mais le mieux est probablement d'intégrer le loader bFLT à Ndless, et de l'exposer aux programmes Ndless

Pourquoi est-ce mieux ? Chaque programme va embarquer une part du même code, non ? J'ai bien conscience que mes connaissances en TI-68k ne couvrent pas l'ensemble des problématiques des loaders/os/etc...

bin tu dois bien voir la différence entre le loader intégré à chaque prog (nostub) et le loader mutualisé (kernel) ?

le premier suxe, le second roxe, voilà

finalement, la nspire est bien une TI