Posté le 24/01/2012 à 13:40 Membre depuis le 28/10/2001, 7625 messages
Je te ferai la même suggestion que pour nRGBlib: utiliser les types de stdint.h, plutôt que "char", "short" et "int" smile
Suivant ce qu'on cherche à remplacer, ils sont plus courts ("unsigned short int" -> "uint16_t") ou plus longs (char -> uint8_t) à écrire, mais plus précis.
Aussi, ta fonction GetPixel me paraît curieuse (copier-coller ?), je penserais plutôt à "uint16_t GetPixel(int x, int y);" smile
(ou même en utilisant typedef uint16_t Color; pour masquer le type)

Un truc qui n'a à ma connaissance pas vraiment été essayé, c'est de piloter en 16 bpp l'horrible écran des Clickpad & Touchpad. On sait qu'il supporte 8 bpp, nDOOM l'utilise ainsi. Mais il y a des chances qu'on ne puisse quand même pas, par ce biais, utiliser les mêmes graphismes sur CX / CM et sur Clickpad / Touchpad.

Pour info, j'ai fait des routines de tile (sprite aligné) 8x8 en 4 bpp, et j'ai commencé une routine de sprite 8x8 smile
Bien sûr, en essayant de tirer parti du retour d'expérience d'ExtGraph, ce qui veut dire: utilisation de macros dans le code ASM !!

La conversion R5G6B5 -> G4 coûte cher. Aucune lib performante ne peut chercher à gérer les modes 4 bpp et 16 bpp avec les mêmes fonctions; mais d'un autre côté, séparer les jeux de fonctions et de sprite veut dire que les possesseurs de Clickpad / Touchpad vont vite se trouver ostracisés, à cause de l'écran à pleurer, et du boulot supplémentaire que nécessite l'utilisation de deux jeux de graphismes.
Et en effet, nous sommes plusieurs à avoir suggéré SDL.
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.
Posté le 24/01/2012 à 14:45 Membre depuis le 16/06/2001, 69781 messages
./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.
Posté le 24/01/2012 à 18:04 Membre depuis le 28/03/2002, 2551 messages
@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
Posté le 24/01/2012 à 18:57 Membre depuis le 16/06/2001, 69781 messages
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 grin
Posté le 24/01/2012 à 19:01 Membre depuis le 28/03/2002, 2551 messages
C'est pas x2 exact....je vais essayé de trouver mieux
Posté le 24/01/2012 à 19:02 Membre depuis le 16/06/2001, 69781 messages
fais x2 exact l'apparence devrait s'améliorer smile

le boo officiel en haut de cette page fait 75x75, sinon faut demander l'original à yaro smile
Posté le 24/01/2012 à 20:36 Membre depuis le 18/06/2001, -26081 message
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 cheeky
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Posté le 24/01/2012 à 21:29 Membre depuis le 15/07/2002, 4490 messages
./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
Posté le 25/01/2012 à 00:53 Membre depuis le 27/04/2006, 60479 messages
Lionel Debroux (./60) :
La conversion R5G6B5 -> G4 coûte cher.
Bôaf...
[code]uint8_t RGB555_to_Gray4[65536];[/code]
grin
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™ embarrassed
avatarZeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo
Posté le 25/01/2012 à 07:19 Membre depuis le 28/10/2001, 7625 messages
Ouais, mais alors, la CX, dont l'écran est bien meilleur, n'est pas une TI smile
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.
Posté le 25/01/2012 à 08:39 Membre depuis le 03/11/2002, 14544 messages
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.
avatarHighway Runners, mon jeu de racing à la Outrun qu'il est sorti le 14 décembre 2016 ! N'hésitez pas à me soutenir :)

https://itunes.apple.com/us/app/highway-runners/id964932741
Posté le 25/01/2012 à 09:27 Membre depuis le 16/06/2001, 69781 messages
Posté le 25/01/2012 à 09:36 Membre depuis le 30/06/2001, 71415 messages
0² est un spécialiste ! #sisi#
avatarProud to be CAKE©®™
The cake is a lie! - Love your weighted companion cube

->986-Studio's Wonder Project!<-
yN a cassé ma signature :o
Posté le 25/01/2012 à 09:44Edité par Brunni le 25/01/2012 à 10:04 Membre depuis le 03/11/2002, 14544 messages
Zerosquare (./68) :
Lionel Debroux (./60) :
La conversion R5G6B5 -> G4 coûte cher.
Bôaf...
[code]uint8_t RGB555_to_Gray4[65536];[/code]
grin

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 ^^
avatarHighway Runners, mon jeu de racing à la Outrun qu'il est sorti le 14 décembre 2016 ! N'hésitez pas à me soutenir :)

https://itunes.apple.com/us/app/highway-runners/id964932741
Posté le 25/01/2012 à 09:51 Membre depuis le 18/06/2001, -26081 message
Zerosquare (./68) :
uint8_t RGB555_to_Gray4[65536];

Bourrin grin
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Posté le 25/01/2012 à 10:11 Membre depuis le 30/06/2001, 71415 messages
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 grin



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);
[...]
avatarProud to be CAKE©®™
The cake is a lie! - Love your weighted companion cube

->986-Studio's Wonder Project!<-
yN a cassé ma signature :o
Posté le 25/01/2012 à 14:58 Membre depuis le 27/04/2006, 60479 messages
Hey ! Je ne t'ai pas donné l'autorisation de diffuser mon code sous ZPL ! rage

( grin )
avatarZeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo
Posté le 25/01/2012 à 15:46 Membre depuis le 30/06/2001, 71415 messages
Vu l'extrait, ça limite les possibilitée de copie wink
avatarProud to be CAKE©®™
The cake is a lie! - Love your weighted companion cube

->986-Studio's Wonder Project!<-
yN a cassé ma signature :o
Posté le 25/01/2012 à 18:22Edité par Lionel Debroux le 25/01/2012 à 18:35 Membre depuis le 28/10/2001, 7625 messages
Je connais aussi http://alienryderflex.com/hsp.html . Bon, évidemment, avec les coefficients flottants, c'est inenvisageable pour de l'embarqué grin
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.
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.
Posté le 25/01/2012 à 18:34 Membre depuis le 15/07/2002, 4490 messages
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 oui
Posté le 25/01/2012 à 19:34 Membre depuis le 30/06/2001, 71415 messages
./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..
avatarProud to be CAKE©®™
The cake is a lie! - Love your weighted companion cube

->986-Studio's Wonder Project!<-
yN a cassé ma signature :o
Posté le 25/01/2012 à 22:24 Membre depuis le 27/04/2006, 60479 messages
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é hehe
avatarZeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo
Posté le 25/01/2012 à 22:35 Membre depuis le 30/06/2001, 71415 messages
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...
avatarProud to be CAKE©®™
The cake is a lie! - Love your weighted companion cube

->986-Studio's Wonder Project!<-
yN a cassé ma signature :o
Posté le 03/04/2012 à 18:57 Membre depuis le 28/10/2001, 7625 messages
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 smile

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 smile
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 smile
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 smile
Une telle intégration devrait accélérer l'adoption de bFLT, par nSDL par exemple.
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.
Posté le 03/04/2012 à 22:29 Membre depuis le 16/06/2001, 69781 messages
très beau!
Posté le 04/04/2012 à 18:52 Membre depuis le 18/06/2001, -26081 message
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 ?
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Posté le 04/04/2012 à 19:13 Membre depuis le 28/10/2001, 7625 messages
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 smile
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 smile
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.
Posté le 04/04/2012 à 19:56 Membre depuis le 18/06/2001, -26081 message
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...
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Posté le 04/04/2012 à 23:49 Membre depuis le 16/06/2001, 69781 messages
bin tu dois bien voir la différence entre le loader intégré à chaque prog (nostub) et le loader mutualisé (kernel) ? grin
Posté le 05/04/2012 à 00:57 Membre depuis le 10/06/2001, 45112 messages
le premier suxe, le second roxe, voilà #modui#
Posté le 05/04/2012 à 08:00 Membre depuis le 16/06/2001, 69781 messages
finalement, la nspire est bien une TI grin